Prev: How you can save fuel and the environment
Next: gfortran and C interoperability problem
From: FX on 12 Jan 2010 17:34
> integer,parameter:: dp = kind(1d0), &
> hperhaps = selected_real_kind(precision(1._dp)+1),&
> hp = merge(hperhaps,dp,hperhaps>0)
> real(hp),parameter:: pi = acos(-1._hp)
> print *,'hp =',hp,'precision =',precision(1._hp)
> print *,'pi =',pi
> end

Definitely works with current gfortran (this is on Mac OS/Intel):

$ gfortran a.f90 && ./a.out
hp = 10 precision = 18
pi = 3.1415926535897932385

--
FX
From: steve on 12 Jan 2010 17:36
On Jan 12, 1:38 pm, jfh <john.har...(a)vuw.ac.nz> wrote:
> On Jan 11, 10:27 pm, Tobias Burnus <bur...(a)net-b.de> wrote:
>
>
>
> > On 01/11/2010 09:16 AM, Dieter Britz wrote:
>
> > > Are there any real Fortran 2003 compilers available? What I have seen
> > > is compilers that are said to have "most" of 2003. Or have I just not
> > > found the right ones?
>
> > I think the Cray has: As far as I understood it, supports all of Fortran
> > 2003. IBM's xlf comes close, but seemingly still lacks user-defined
> > derived-type I/O.
>
> > See: ACM Fortran Forum's December 2009 issue,
> >  http://doi.acm.org/10.1145/1667140.1667145
> > orhttp://fortranwiki.org/fortran/show/Fortran+2003+status(fromthe
> > August 2009 issue of ACM Fortran Forum).
>
> > (Note: I think the "N" for Cray under "international characterset" just
> > means that it does not support UTF-8 - but that's permitted by the
> > Fortran 2003 standard.)
>
> > If you talk about normal PC hardware, I think the answer is no. NAG
> > nagfor v5.2, Intel's ifort v11.1, and GCC's gfortran v4.5 support a lot,
> > but still there are many features unimplemented. Or in other words: One
> > can do most things one wants to do - Fortran 2003 wise - but
> > unfortunately one need to have the list of supported features ready to
> > make sure no unsupported feature slips into one's code. (Add in
> > addition, as the features get implemented in a slightly different order,
> > finding a common subset is even harder and more restrictive.)
>
> > Tobias
>
> > PS: Just for curiosity, which of gfortran's missing Fortran 2003
> > features do you miss most?
> > (Planned for 4.6 are ASSOCIATE construct, fixing bugs in the current
> > polymorphism support, implementation of unlimited polymorphism, and true
> > asynchronous I/O; what really will be implemented? - only the future can
> > tell, which is typical for the more erratic development of a
> > volunteer-based software development.)
>
> The f2003 feature I miss most is being allowed to put elemental
> intrinsics with logical, real or complex arguments in an
> initialization expression. The following program compiles and runs
> with g95 but none of the other 3 compilers I have tried, one of which
> is gfortran.
>
> integer,parameter:: dp = kind(1d0), &
>      hperhaps = selected_real_kind(precision(1._dp)+1),&
>      hp = merge(hperhaps,dp,hperhaps>0)
> real(hp),parameter:: pi = acos(-1._hp)
> print *,'hp =',hp,'precision =',precision(1._hp)
> print *,'pi =',pi
> end
>
> It may be that my gfortran has been superseded: unfortunately our
> systems people don't think updating it is their highest priority. My
> compile-time experience is below:

Works fine with 4.4.3 and 4.5.0 (aka trunk).
At least with gfortran, it appears to be a failure
of your systems people to adequately support
their users.

--
steve

--
steve
From: Tim Prince on 12 Jan 2010 18:51
steve wrote:
> On Jan 12, 1:38 pm, jfh <john.har...(a)vuw.ac.nz> wrote:
>> On Jan 11, 10:27 pm, Tobias Burnus <bur...(a)net-b.de> wrote:

>>
>> It may be that my gfortran has been superseded: unfortunately our
>> systems people don't think updating it is their highest priority. My
>> compile-time experience is below:
>
> Works fine with 4.4.3 and 4.5.0 (aka trunk).
> At least with gfortran, it appears to be a failure
> of your systems people to adequately support
> their users.
>

Even current RHEL/CentOS provide the hopelessly old versions of
gfortran, g++, and binutils. So there will be many installations with a
policy against putting useful versions on the default PATH.
From: card on 12 Jan 2010 23:16
On Jan 11, 4:27 am, Tobias Burnus <bur...(a)net-b.de> wrote:
> On 01/11/2010 09:16 AM, Dieter Britz wrote:
>
> > Are there any real Fortran 2003 compilers available? What I have seen
> > is compilers that are said to have "most" of 2003. Or have I just not
> > found the right ones?
>
> I think the Cray has: As far as I understood it, supports all of Fortran
> 2003. IBM's xlf comes close, but seemingly still lacks user-defined
> derived-type I/O.
>
> See: ACM Fortran Forum's December 2009 issue,
>  http://doi.acm.org/10.1145/1667140.1667145
> orhttp://fortranwiki.org/fortran/show/Fortran+2003+status(from the
> August 2009 issue of ACM Fortran Forum).
>
> (Note: I think the "N" for Cray under "international characterset" just
> means that it does not support UTF-8 - but that's permitted by the
> Fortran 2003 standard.)
>
> If you talk about normal PC hardware, I think the answer is no. NAG
> nagfor v5.2, Intel's ifort v11.1, and GCC's gfortran v4.5 support a lot,
> but still there are many features unimplemented. Or in other words: One
> can do most things one wants to do - Fortran 2003 wise - but
> unfortunately one need to have the list of supported features ready to
> make sure no unsupported feature slips into one's code. (Add in
> addition, as the features get implemented in a slightly different order,
> finding a common subset is even harder and more restrictive.)
>
> Tobias
>
> PS: Just for curiosity, which of gfortran's missing Fortran 2003
> features do you miss most?
> (Planned for 4.6 are ASSOCIATE construct, fixing bugs in the current
> polymorphism support, implementation of unlimited polymorphism, and true
> asynchronous I/O; what really will be implemented? - only the future can
> tell, which is typical for the more erratic development of a
> volunteer-based software development.)

Thought I'd get my 2 cents in. I really want to see FINAL binding
implemented in derived types.

-David
From: Jerry DeLisle on 13 Jan 2010 00:01
On 01/12/2010 01:38 PM, jfh wrote:
> On Jan 11, 10:27 pm, Tobias Burnus<bur...(a)net-b.de> wrote:
>> On 01/11/2010 09:16 AM, Dieter Britz wrote:
>>
>>> Are there any real Fortran 2003 compilers available? What I have seen
>>> is compilers that are said to have "most" of 2003. Or have I just not
>>> found the right ones?
>>
>> I think the Cray has: As far as I understood it, supports all of Fortran
>> 2003. IBM's xlf comes close, but seemingly still lacks user-defined
>> derived-type I/O.
>>
>> See: ACM Fortran Forum's December 2009 issue,
>> http://doi.acm.org/10.1145/1667140.1667145
>> orhttp://fortranwiki.org/fortran/show/Fortran+2003+status(from the
>> August 2009 issue of ACM Fortran Forum).
>>
>> (Note: I think the "N" for Cray under "international characterset" just
>> means that it does not support UTF-8 - but that's permitted by the
>> Fortran 2003 standard.)
>>
>> If you talk about normal PC hardware, I think the answer is no. NAG
>> nagfor v5.2, Intel's ifort v11.1, and GCC's gfortran v4.5 support a lot,
>> but still there are many features unimplemented. Or in other words: One
>> can do most things one wants to do - Fortran 2003 wise - but
>> unfortunately one need to have the list of supported features ready to
>> make sure no unsupported feature slips into one's code. (Add in
>> addition, as the features get implemented in a slightly different order,
>> finding a common subset is even harder and more restrictive.)
>>
>> Tobias
>>
>> PS: Just for curiosity, which of gfortran's missing Fortran 2003
>> features do you miss most?
>> (Planned for 4.6 are ASSOCIATE construct, fixing bugs in the current
>> polymorphism support, implementation of unlimited polymorphism, and true
>> asynchronous I/O; what really will be implemented? - only the future can
>> tell, which is typical for the more erratic development of a
>> volunteer-based software development.)
>
> The f2003 feature I miss most is being allowed to put elemental
> intrinsics with logical, real or complex arguments in an
> initialization expression. The following program compiles and runs
> with g95 but none of the other 3 compilers I have tried, one of which
> is gfortran.
>
> integer,parameter:: dp = kind(1d0),&
> hperhaps = selected_real_kind(precision(1._dp)+1),&
> hp = merge(hperhaps,dp,hperhaps>0)
> real(hp),parameter:: pi = acos(-1._hp)
> print *,'hp =',hp,'precision =',precision(1._hp)
> print *,'pi =',pi
> end
>
> It may be that my gfortran has been superseded: unfortunately our
> systems people don't think updating it is their highest priority. My
> compile-time experience is below:
>
> rimu[~]$ gfortran -v
> Using built-in specs.
> Target: i386-redhat-linux
> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
> infodir=/usr/share/info --enable-shared --enable-threads=posix --
> enable-checking=release --with-system-zlib --enable-__cxa_atexit --
> disable-libunwind-exceptions --enable-libgcj-multifile --enable-
> languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --
> disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-
> gcj-1.4.2.0/jre --with-cpu=generic --host=i386-redhat-linux
> Thread model: posix
> gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)
> rimu[~]$ gfortran testinit.f90
> In file testinit.f90:4
>
> real(hp),parameter:: pi = acos(-1._hp)
> 1
> Error: Constant expression required at (1)
> In file testinit.f90:5
>
> print *,'hp =',hp,'precision =',precision(1._hp)
> 1
> Error: Missing kind-parameter at (1)
> rimu[~]$
>
> John Harper

Go to the gfortran wiki and download a binary of 4.5 for your machine and
install it locally. It should work fine. No point waiting for IT admin people.
You could also compile your own, its not too hard.

Jerry
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: How you can save fuel and the environment
Next: gfortran and C interoperability problem