[Bug fortran/35658] New: [4.3 regression] Bad interaction on ia64 between -funroll-loops -fno-automatic -O2 and common block variable

["kmccarty at debian dot org" <gcc-bugzilla at gcc dot gnu dot org>]

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)kmccarty@merulo:~$ 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