Severe issue with gfortran (from gcc) with binary builds

["Markus W. Weißmann"]

Hi all,

as we discussed off-list: I cannot reproduce this problem with the binary packages on 10.7.

If you want to help us track this error down, please create a file "test.f90" and put Thomas example program text in it:

program test
implicit none
print *, selected_int_kind(13)
print *, selected_real_kind(p=6,r=37)
print *, selected_real_kind(p=15,r=307)
end program test

save and compile with

$> gfortran-mp-4.5 test.f90 -o test
or whatever version of gcc you have installed (4.3 up to 4.8 should do)

execute 'test' and see if it prints (correctly):
8
4
8

Thanks!


Best regards

-Markus

On 17 May 2012, at 10:57, Thomas Robitaille wrote:

> Hi all,
> 
> I've identified a major issue which occurs with gfortran in MacPorts,
> but since I can't identify which dependency is responsible (all I know
> is that it's due to the binary builds), I thought I'd post here to ask
> for help.
> 
> To give some background, Fortran has the option to declare floats
> using real(kind) where kind is a number related to the default
> precision, and typically (although not in the fortran standard) this
> corresponds to the number of bytes used to store values. So real(4) is
> a 32-bit float, real(8) is a 64-bit float, etc. All major fortran
> compilers stick to this convention for reasons of backward
> compatibility. However, the standard now recommends (looking to the
> future) that rather than use e.g. 4 or 8, one uses helper functions to
> determine the correct kind for a desired precision. So with all major
> compilers (including gfortran), the following code:
> 
> program test
> 
> implicit none
> 
> print *, selected_int_kind(13)
> print *, selected_real_kind(p=6,r=37)
> print *, selected_real_kind(p=15,r=307)
> 
> end program test
> 
> returns
> 
> 8
> 4
> 8
> 
> However, after upgrading outdated ports recently, the macports
> gfortran suddenly returned
> 
> 16
> 8
> 10
> 
> which is making it impossible to compile a lot of legacy code (and
> causes values to take up twice as much RAM). What happened was that
> one of the dependencies for gcc got upgraded to the binary build, and
> this causes all the different versions of gfortran (from gcc43 to
> gcc47) to change their output (without being upgraded themselves,
> which tells me that it is an issue with a dependency, not gcc itself).
> 
> If I install MacPorts (on 10.7) then gcc45 from scratch with binary
> packages, the issue is there. If I install all packages from scratch
> with the -s flag, the issue disappears. This suggests to me that there
> is an issue with one of the binary builds.
> 
> Of course, the temporary solution for me is simply to force the -s
> flag to always be used, but I think this issue should be fixed, as it
> makes the gfortran compilers in MacPorts unusable otherwise.
> 
> Any ideas?
> 
> Thanks,
> Tom
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev