| Summary: | dev-libs/libf2c - Integer size wrong on 64-bit systems | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Norman Yarvin <norman.yarvin> |
| Component: | [OLD] Library | Assignee: | Gentoo Science Related Packages <sci> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | Keywords: | EBUILD, PATCH |
| Priority: | Normal | ||
| Version: | 10.0 | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 469000 | ||
| Bug Blocks: | |||
| Attachments: |
Patch to libf2c
Ebuild for f2c incorporating the Debian patch test.f Subroutine for test program |
||
|
Description
Norman Yarvin
2013-05-03 03:53:24 UTC
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 + |