(cc'ing macports-dev) > The problem is actually with MacPorts 4.3.2. A little more accurately, this > is NOT an actual bug. The problem is that the behavior you are seeing is > allowed under the Fortran standard -- that's why selected_int_kind exists in > the first place.
This is wrong. The Fortran standard, and in particular gfortran, call for the *smallest* integer type: http://gcc.gnu.org/onlinedocs/gfortran/SELECTED_005fINT_005fKIND.html For selected_int_kind(5), this *must* be INTEGER*4 (4 bytes = 32 bits; pow(2,32)/2-1 will suffice 5 for digits) > I had to issue a patch for a piece of software that used > selected_real_kind(), but assumed that it would always return 8 as used. From > all the searching I did, I found that this behavior was perfectly within the > Fortran standard, and that we had to become compliant with it. > > My suggestion is to avoid roll-your-own precision to avoid problems like > this. If you need to use it, make sure you always use the enquiry intrinsics > (selected_real_kind and selected_int_kind), and never assume it will take a > particular value. That's what this piece of software does, actually (uses select_*_kind). > To reiterate, this behavior ONLY arose when I built all my ports with Xcode > 4.3.2, and never with older Xcodes (that is, if I built gcc4x with Xcode > 4.3.2, it would happen regardless of which FCC I built). > > I agree the behavior differs in my experiences with Linux, but there are > other OSes and compilers that behave differently as well (or so I read) There is a bug here but it's not with gcc / gfortran. It appears to be gmp; and it seems to occur when missing the 10.6 sdk. I don't know why it happens, but that look like the common failure (i.e. using MacPorts's gmp generated from the buildbot will expose this bug). Or it could be the +universal logic in the gmp Portfile. For my machine, I have the 10.6 sdk so I needed to uninstall gmp and build it from source (using the -s option): $ sudo port uninstall --follow-dependents gmp $ sudo port -vs install gcc47 (or gcc46, gcc48; all gcc ports experience this bug with gmp) This really, *really* needs to be fixed on the buildbot. Is there any particular reason the buildbot doesn't have the 10.6 SDK? The test case is easy to see with Victor's attached fortran test (which I reattached to this email). The output should be: $ ./a.out int4: 4 int8: 8 Are there any other macport devs that can test building gmp / gcc47 on their local machine to see if the output matches (e.g. just run my two above command that uninstalls gmp and its dependents, then install gcc47 and its dependencies from source)? Also, it would be nice if all compilers included their debug symbols (i.e. run dsymutil *.dylib in the destroot phase) which I put a patch here: https://trac.macports.org/attachment/ticket/33821/base-create-dsym.patch This would stop millions of warnings when using gdb with *anything* compiled by one of the compilers provided by MacPorts. The impact of including the .dSYM files is extremely low but saves so much frustration on the users.
sizeof-ftn.f90
Description: Binary data
_______________________________________________ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
