Re: SPEC2000 252.eon generates invalid results when compiled -O3 with g++ 3.3

[Vladimir Makarov <vmakarov at redhat dot com>]

Casey Leedom wrote:
> 
> --- Joe Buck <jbuck at synopsys dot com> wrote:
> > On Thu, Mar 27, 2003 at 01:35:42PM -0800, Casey Leedom wrote:
> > >   I'm trying to track down a patch for what appears to be a g++ 3.3
> > > optimization bug with the SPEC2000 252.eon benchmark.  When I compile this
> > > "-m32 -O0" or "-m64 -O3" I get correct results.  But if I use anything
> > other
> > > than -O0 with -m32 I end up with incorrect results.  Is anyone aware of
> > this
> > > bug and is there a patch available for it?  Thanks!
> >
> > You don't mention a platform, but since you mention -m64 I guess sparc.
> > Right?  Also, is there a PR for this?
> 
>   Actually this is an Opteron system so I'm using the x86 and x86-64 stuff from
> gcc 3.3 provided by AMD.
> 
>   I've been away from the gcc world for quite some time so I'm not sure how
> problem reports are being handled these days or how to search the database.  (I
> am of course more than willing to learn!)  There is a comment in the
> configuration file for x86 linux that has the following in it:
> 
> -----<BEGIN EXCERPT config/ia32-linux-gcc.cfg>-----
> ...
> 252.eon=default=default=default:
> EXTRA_CXXFLAGS=-DHAS_ERRLIST
> OPTIMIZE=-O0
> # Optimization level -g or -O0 must be used to obtain
> # a valid reference run using the default compilers on
> # the RedHat 5.2 distribution for Intel
> # the RedHat 6.0 distribution for Intel
> # the Suse 6.1 distribution for Intel
> # if GCC 2.95.1 or later is used the the suggested default
> # optimization level of -O3 -fomit-frame-pointer may be used
> # by commenting out the line OPTIMIZE=-O0 in the stanza for 252.eon above.
> ...
> -----<END EXCERPT config/ia32-linux-gcc.cfg>-----
> 
> As I mentioned in my first message, using -O3 -m64 works fine, but I can't use
> anything other than -O0 with -m32.  The code does compile, it just generates
> invalid results.  It looks like some bad floating point optimizations have been
> done.  I'll run this on a different CPU just to be sure.
> 

IMHO, EON is placed into SPECInt2000 by mistake.  It heavily uses
floating point numbers, vector and matrixes.  It is a typical SPECFP
stuff.

The problem may be in usage x86 floating point stack with 80-bit
floating point numbers without conversion them into 64-bit ones.  The
calculation error (as I understand it is a ray tracing recurrent
algorithm, therefore the discrepancy can be big) is accumulated and
results in different from the expected one.

When -O0 is used, fp reg values are converted into 64-bit ones during
storing in memory.  You could try to use -ffloat-store or just ignore
the mistake by changing abstol value in object.pm for eon.

Vlad