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@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev