bug in g77 -O2 optimization found

[Jonathan DeSena <jonathan dot desena at jhuapl dot edu>]

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.