bug in g77 -O2 optimization found -- resending with attachment

[Jonathan DeSena]

Originator Jonathan DeSena
Organization     JHU/APL
Confidential NO

Synopsis
     g77 generates incorrect code for a particular looping construct 
when optimization of -O2 or higher is used.

Severity serious
Priority medium
Category fortran
Class     wrong-code
Release     2.95.3 19991030 (prerelease)
Environment Linux Mandrake 7.2 on a Pentium III
Description
     A simple old style fortran loop operating on a small array produces 
incorrect results when optimization -O2 or higher is used to compile the 
code.  The program seems to be accessing the wrong array member, or 
using the wrong subscript inside the if statement. ARRAY(I) should not 
equal ARRAY(I1) (where I1=I+1).  When optimized ARRAY(I) seems to access 
ARRAY(I1), thus any calculation depending on such values in a real 
program are incorrect.  Adding/Removing certain lines seems to eliminate 
the problem.  See attached source code.

This same code compiles correctly under Sun's f77 for Solaris/SPARC 
under all optimization levels.  The problem was noted when porting code 
from Solaris/SPARC to ix86/Linux.

I worry that I may not be able to as easily find similar cases in other 
code where the output might not be as noticeably wrong as it was in this 
case. For what appears to be such a simple (albeit deprecated) code 
sample, the incorrect results are distressing.  I hope this can be fixed 
rather quickly.

How-To-Repeat
     Test case source code file test.for is attached.  The following 
shows compilation and execution on the command line:
_______________________________________________________________________
$ g77 -v -O2 -o test test.for
g77 version 2.95.3 19991030 (prerelease) (from FSF-g77 version 0.5.25 
19991030 (prerelease))
Driving: g77 -v -save-temps -O2 -o test test.for -lg2c -lm
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/specs
gcc version 2.95.3 19991030 (prerelease)
  /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/f771 test.for -quiet 
-dumpbase test.f -O2 -version -fversion -o test.s
GNU F77 version 2.95.3 19991030 (prerelease) (i586-mandrake-linux) 
compiled by GNU C version 2.95.3 19991030 (prerelease).
GNU Fortran Front End version 0.5.25 19991030 (prerelease)
  as -V -Qy -o test.o test.s
GNU assembler version 2.10.90 (i586-mandrake-linux) using BFD version 
2.10.0.24
  /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/collect2 -m elf_i386 
-dynamic-linker /lib/ld-linux.so.2 -o test /usr/lib/crt1.o 
/usr/lib/crti.o /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/crtbegin.o 
-L/usr/lib/gcc-lib/i586-mandrake-linux/2.95.3 
-L/usr/i586-mandrake-linux/lib test.o -lg2c -lm -lgcc -lc -lgcc 
/usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/crtend.o /usr/lib/crtn.o
$ ./test
  IF THESE TWO NUMBERS ARE EQUAL, THE CODE IS BAD:  60.  60.
_______________________________________________________________________

Fix
     Actually, the only real fix is to get the compiler -O2+ 
optimizations working correctly.  However, it is possible to replace the 
misbehaving code with a logically equivalent while loop (not Fortran 77 
standard, but most compilers I know accept it).  This is what I have 
done to get the code where this problem appeared working correctly.