This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: gfortran 4.1.1 | AMCL 3.6.0
Hi Evan,
Evan Cooch wrote:
>> - The "gfortran64/" version is compiled with gfortran 4.1.x and one
>> should use at least 4.1.2.
>
> Alas, gfortran 4.1.1 is currently the 'latest' release for FC5 machines.
Well, the distributions have often patches which are newer thus you
might be lucky. Note that 4.1.1 should also work, but might contain
bugs, which were fixed in later gfortran versions. (cf. below.)
> But, 4.1.1 does seem to compile with acml3.6.0, so I'll assume for now
> things are fine.
All 4.1.x compilers shall be binary compatible (at least upward
compatible, if the compiler of the library is older than your current
compiler, you are fine).
ACML 3.6.0 is build with gfortran 4.1.0 for that reason. But due to a
bug in gfortran 4.1.0 (accuracy bug, detected using the GAMESS
benchmark), the ACML will be rebuild with 4.1.2. (I don't know the
details, ask AMD if you want to know more;
http://developer.amd.com/acml.jsp; version on that download site
contains still the gfortran 4.1.0 one.)
For completeness: The _mp OpenMP version is build with "4.2.0 20061114
(prerelease)" as "strings *.so |grep -i gcc" reveals.
* * *
Not that it will work with the current ACML, but using gfortran 4.2.0
and 4.3.0 might be also an option. They are available from
http://gcc.gnu.org/wiki/GFortranBinaries and are - depending on the
program - somewhat faster than gfortran 4.1.x and contain fewer Fortran
bugs.
(Warning: 4.2.0 will build with current ACML [_mp, OpenMP] but it may
fail at runtime [crash] due to library changes. You need to wait for the
next ACML version to build programs with gfortran 4.2.0 and ACML.)
Tobias,
who hopes that the ABI of gfortran will stabilize or at least offer
versioned symbols. Currently, using binary-only libraries is a mess.