Created attachment 347196 [details] Patch to libf2c Libf2c translates Fortran integers into the C type "long", which is 64 bits on 64-bit systems. The Debian folks ran into this problem: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=442018 and have a patch (attached) that restores it to the proper 32-bit type, which Gentoo should probably pick up. According to that discussion, this is required by the Fortran standard: integers need to be the same size as reals. I haven't looked into the standard myself, but certainly a lot of old code depends on that property. This has caused problems before, e.g. with dev-lang/R, which tried to offer f2c as an option but had to give it up because of this. (See bug 61042.)
Created attachment 347198 [details] Ebuild for f2c incorporating the Debian patch
Any test case for this?
I could easily provide a small test case, and will if you like, but I don't think there'd be much point. Any piece of code that allocates an array of integers by carving it out of an array of reals would run into this, and since Fortran 77 had no real memory allocation, a lot of programs allocated memory that way. Probably the only reason this hasn't been fixed yet in Gentoo is that f2c doesn't get used much these days. The thing I'd be a bit leery of is whether changing the behavior would break anything. Even taking 32-bit ints as the standard, real Fortran compilers have a long history of supporting nonstandard behavior because people have gotten used to it. Still, it seems unlikely that anyone would have been developing for f2c on 64-bit machines, which is what would cause breakage here. Slightly more likely is that people might be using old code but on larger problems, where they now might need some integer to be 64 bits -- yet still, probably any other Fortran compiler would break that code. And this certainly wasn't intended behavior by the f2c authors: the man page gives options for dealing with Fortran INTEGER*8 variables (8-byte, 64-bit variables), and none of those options is to make them the default integer type (whereas there is an option to make INTEGER variables into C 'short'; the authors were still thinking about 16-bit machines when they rendered the default INTEGER as "long int").
You don't need to convince me. I already got a fedback from our fortran guys and will apply the patch. But I like to test something before and after just to see that it works. So if it isn't to much work, please provide some lines of code. Expect the patch to be applied tomorrow noon.
Created attachment 347470 [details] test.f Okay, here's a test program, in two files. (I'll post the second one next; if all the code is in one file, gcc complains.) It should print out: t( 1) = 0. t( 2) = 0. t( 3) = 0. t( 4) = 0. t( 5) = 0. t( 6) = 6. t( 7) = 7. t( 8) = 8. t( 9) = 9. t( 10) = 10. t( 11) = 11. t( 12) = 12. but with 64-bit integers it prints: t( 1) = 0. t( 2) = 0. t( 3) = 0. t( 4) = 0. t( 5) = 0. t( 6) = 0. t( 7) = 0. t( 8) = 0. t( 9) = 0. t( 10) = 0. t( 11) = 11. t( 12) = 12.
Created attachment 347472 [details] Subroutine for test program Compile with: f2c test.f f2c mung.f cc test.c mung.c -lf2c
Thanks a lot.
+*libf2c-20110801-r3 (08 May 2013) + + 08 May 2013; Justin Lecher <jlec@gentoo.org> +libf2c-20110801-r3.ebuild, + +files/libf2c-20110801-64bit-long.patch, metadata.xml: + Fix long on 64bit systems, #468352 +
