Package: gfortran-4.3 Version: 4.3-20080202-1 Severity: normal Hi, 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). Please see the complete test case I've provided at http://people.debian.org/~kmccarty/ia64-gfortran-test-fail.tar.gz 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.) 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 B. McCarty <kmccarty@gmail.com> WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751
Attachment:
signature.asc
Description: OpenPGP digital signature