Re: g77-20000626 miscompilation of nested loops at -Os -funroll-loops (x86)

["Tim Prince" <tprince at computer dot org>]

I have a copyright assignment on file with FSF, and I am self employed, so you are welcome to them.  I believe they are sufficiently
altered from the NASA site version of LFK.  If I could figure out how to make them give a failure indication on their own, I would
have done so.  The erroneous result on the first differs from the correct one only in the 9th decimal, and not on all loop counts.
Likewise the second appears to produce a correct result for certain loop counts, even when it is mis-compiled.

Tim Prince
----- Original Message -----
From: "Billinghurst, David (CRTS)" <David.Billinghurst@riotinto.com.au>
To: "'Tim Prince'" <tprince@computer.org>; <gcc-bugs@gcc.gnu.org>
Sent: Tuesday, June 27, 2000 7:02 PM
Subject: RE: g77-20000626 miscompilation of nested loops at -Os -funroll-loops (x86)


> What is the copyright on these.  I am happy to knock them into a testsuite
> patch and submit it if there are no issues.
>
> > -----Original Message-----
> > From: Tim Prince [SMTP:tprince@computer.org]
> > Sent: Wednesday, 28 June 2000 11:48
> > To: gcc-bugs@gcc.gnu.org
> > Subject: g77-20000626 miscompilation of nested loops at -Os
> > -funroll-loops (x86)
> >
> > This bug has remained in gcc-2.96 for months; all other bugs which I have
> > reported have been fixed.  The two nested loop groups from
> > Livermore Fortran Kernels which are being miscompiled are isolated in the
> > files k18a.f and k23.f.  These files continue to compile
> > correctly with all options tested under gcc-2.95.2, and fail under
> > gcc-2.96 only with the combination -Os -funroll-loops.  The
> > options -march=pentiumpro and -ffast-math make no difference, and correct
> > results are obtained without -funroll-loops, with the
> > combinations -O -funroll-loops, -O2 -funroll-loops, and with a subroutine
> > call inserted to avoid having nested loops in one
> > compilation unit.  The fact that these examples have a fixed count on the
> > outer loop appears to be coincidental;  making them
> > variable does not affect the problem.  If the fixed count outer loop is
> > unrolled in source code, that also eliminates the problem.
> >
> > Tim Prince << File: llnk.f.gz >>  << File: kb.f >>  << File: k18a.f >>  <<
> > File: k23.f >>