strange gfortran problem

Sean Farley sean.michael.farley at gmail.com
Sat May 5 11:54:34 PDT 2012


(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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sizeof-ftn.f90
Type: application/octet-stream
Size: 173 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20120505/cfe11c0b/attachment.obj>


More information about the macports-dev mailing list