Hi, [This bug was initially submitted to the Debian BTS at http://bugs.debian.org/466911 -- at the request of Debian's gcc maintainer, I am also sending it here]
In porting CERNLIB to gfortran, I've found an apparent gfortran compiler bug that results in incorrect code on ia64 (Itanium) with the compiler flags -funroll-loops -fno-automatic -O2 (or higher), possibly due to a bad interaction between these flags and a common block variable used in a computed GO TO statement of the form "GO TO (1,2,3,4), L". The bug ONLY occurs in gfortran-4.3 -- I have tested that it does NOT happen in gfortran-4.1 (4.1.2-19), gfortran-4.2 (4.2.3-1), or g77-3.4 (3.4.6-6). The output of gfortran-4.3 -v is: (sid)[EMAIL PROTECTED]:~$ gfortran-4.3 -v Using built-in specs. Target: ia64-linux-gnu Configured with: ../src/configure linux gnu Thread model: posix gcc version 4.3.1 20080309 (prerelease) (Debian 4.3.0-1) Please see the complete test case I've provided at http://people.debian.org/~kmccarty/ia64-gfortran-test-fail.tar.gz [Note, I have updated this test case tarball to the gfortran version noted above since I originally submitted this bug to the Debian BTS.] Notes on the test case: 1) The code that gets mis-compiled is in c201s.F (this can be verified by building c201s.F with -O0 and building all the rest with -funroll-loops -fno-automatic -O2, then linking and running the test program c201test) 2) If *any* of the compiler flags are changed (remove -funroll-loops, remove -fno-automatic, or lower the optimization to -O1) the code is built OK. 3) I have put the output of gfortran-4.3 on ia64 (files c201s.f, c201s.s, and c201s.o) for various compiler flag combinations in subdirectories in the test case tarball. Also the output of the test program when run, in the file output.txt in each subdirectory. (Subdirectories are named first after whether the test succeeds, and second after the specific compiler flags used.) You can quickly regenerate this output for all the various flag combinations in the test case with "make output". 4) I believe the problem is that the variable L in common block "FLABEL" is not seen as having the correct value (should be 1, is set to that value in c201m.F prior to any call of C201S) within c201s.F. 5) If I make any tweak to L in c201s.F, the bug disappears. (Argh, heisenbug!) For instance, any of the following tweaks individually causes the test program to succeed: a) changing L to a local variable initialized to the value 1 at the top of c201s.F b) setting L=1 at the top of c201s.F (keeping it in the common block) c) printing the value of L to stdout at the top of c201s.F with a WRITE statement d) printing the literal string 'L=n' to stdout (n being one of 1,2,3,4) immediately after each label that the first GO TO jumps to (i.e. the value of L is not even directly read from). Hence I was not able to simplify the test case any, unfortunately. best regards, Kevin McCarty -- Summary: [4.3 regression] Bad interaction on ia64 between - funroll-loops -fno-automatic -O2 and common block variable Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kmccarty at debian dot org GCC build triplet: ia64-linux-gnu GCC host triplet: ia64-linux-gnu GCC target triplet: ia64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35658
