g77 optimizer bug ???

[Ivan Powis <Ivan dot Powis at Nottingham dot ac dot uk>]

Ivan Powis
School of Chemistry
University of Nottingham
Nottingham NG7 2RD
UK

Tel +44 115 9513467
Fax +44 115 9513562
Email Ivan.Powis@Nottingham.ac.uk

Description:

Under certain input conditions optimised (-O) code will apparently create
corrupted array elements (NaNs). This occurs in a large and elderly
program which has been extensively used and ported to various machines
without previously displaying this problem. It has also been used for many
months on the current Linux/G77 system without problem. The changes to input
data which first threw up this problem are not logically related to that
part of the code where the problem becomes evident.

With this input:
(1)  compiling g77 -g    works fine, as expected
(2)  compiling g77 -O -g produces the corruption (NaNs)
(3)  compiling g77 -g -O -ffloat-store  works fine
(4) compiling all program modules separately with no optimisation (as
     in 1), except for one specific subroutine "setup" which was
     compiled with -O optimisation as in (2) also leads to the same
     incorrect behaviour.
(5) conversely compiling everything but "setup" with optimization as in(2)
    but compiling "setup" as in either (1) or (3) produces working code.

I have produced a (slightly) cut-down demonstration program to show this:
demo.f		main plus all needed function/subroutines except ...
demosetup.f	this is the module which can be compiled separately to
		either enable or disable the 'bug'
isnan.c		a 'C' wrapper to test for NaNs in the demo program


The key part seems to be  the following section from demosetup.f where it
calls YLM1. I have put debugging code around this call to
check and flag for the NaNs which are seemingly returned from
YLM1. (I have also put such checks in YLM1 and interestingly
the corruption is evident at the end of this routine - it is not
clear to me why the compilation options on the calling module (setup)
affect the operation of the called module (ylm1))


  315	
  316	            write(0,*) '***dbg base offset k is ',k
  317	            do ijk=k,k+2*matdim-1
  318	               if (isnan(%val(YL(ijk))) .ne. 0) then
  319	                  write(0,*) 'Y(',Ijk,') is NaN before'
  320	                  bad=.true.
  321	               endif
  322	            enddo
  323	
  324	c            CALL YLM1(NLAB,ZMU,PHI,%VAL(%LOC(YL(K))),MATDIM)
  325	            CALL YLM1(NLAB,ZMU,PHI,YL(K),MATDIM)
  326	c            CALL YLM1(NLAB,ZMU,PHI,(YL(K)),MATDIM)
  327	c            CALL YLM1(NLAB,ZMU,PHI,YL,MATDIM)
  328	
  329	            do ijk=k,k+2*matdim-1
  330	               if (isnan(%val(YL(ijk))) .ne. 0) then
  331	                  write(0,*) 'Y(',Ijk,') is NaN after'
  332	                  bad=.true.
  333	               endif
  334	            enddo
  335	
 ~//~
  354	      if (bad) stop 'NANs found'
  355	      stop 'ok'
  356	
  357	      RETURN

For the purposes of the demonstration at the end of setup a STOP
is executed which will identify whether or not NaNs were detected.

Other notes:

Various combinations of additional compiler options
(-malign-double -fno-automatic -fbounds-check) on the original
program and on the demonstration have been tried without seeming to
influence the above stated conclusions with one EXCEPTION:

	  I noticed using both -fbounds-check AND -fno-automatic with
	  an optimised compilation of demosetup causes correct
	  operation. Since no array bound errors are ever reported I
	  guess that the effect of these additional options is
	  indirect, perhaps just some subtle re-ordering of the
	  emitted code.

I also noted that trying the alternative call on setup:325 in place
of setup:324 generates segmentation errors! Since the only difference
is that the argument YL(K) is enclosed in parentheses in the source
code (which to my understanding should make no difference) this
also seems somewhat 'buggy' ?

This is largely inherited code which I inherited - its not always
very pretty, but it has been extensively tested without showing this
behaviour before.

To run demonstration:

It needs three input files (provided) fort.2 fort.3 fort.4 to be in
the working directory. Compile, link (then assuming the executable is
called demo)

$ demo <demo.in >/dev/null

There will be some debugging output on stdout before the STOP is
executed.

An alternative pair of files FORT.2 FORT.4 can be substituted
for fort.2 and fort.4 by renaming them. This is very similar data
but which does not produce any errors. Nb the data which is
logically being processed in the subroutine setup is that associated
with the content of fort.3 which is the same in both cases.
The other part of the input in 'demo.in' which is to be read
from stdin is also the same in both cases.

My system is Linus Mandrake 7.2

Linux dellboy 2.2.17-21mdk #1 Thu Oct 5 13:16:08 CEST 2000 i686 unknown

$  g77 -v -O -g demo.f isnan.o -o demo
g77 version 2.95.3 19991030 (prerelease) (from FSF-g77 version 0.5.25 19991030\
     (prerelease))
Driving: g77 -v -O -g demo.f isnan.o -o demo -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 demo.f -quiet -dumpbase\
  demo.f -g -O -version -fversion -o /tmp/ccO4vLjM.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 /tmp/cc1rLGgV.o /tmp/ccO4vLjM.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 demo /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\
 /tmp/cc1rLGgV.o isnan.o -lg2c -lm -lgcc -lc -lgcc\
 /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/crtend.o /usr/lib/crtn.o

Please note that an earlier copy of the original executable,
compiled under Mandrake 7.1 (I believe it was the
g77 2.95.2 compiler) also showed this errant behaviour. I no longer
have that earlier compiler, but this possible to be a problem
with more than just my current Mandrake (pre-release ?) supplied version.

demo.shar