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

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

[Casey Leedom]

Hi,

  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!

Casey

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

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

[Joe Buck]

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?
 

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

[Casey Leedom]

--- Joe Buck <jbuck@synopsys.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.

Casey

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

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

[Jan Hubicka]

> --- Joe Buck <jbuck@synopsys.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.

The problem actually is that 386 uses x87 for FP operations that does
use 80bit values for temporaries.  The eon depends on roundoff errors
and thus get slightly different results.
The way to fix it is to ldpreload simple constructor that does set
control word to 64bits like windows does.

Honza
> 
>   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.
> 
> Casey
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
> http://platinum.yahoo.com

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

[Casey Leedom]

--- Jan Hubicka <jh@suse.cz> wrote:
> 
> The problem actually is that 386 uses x87 for FP operations that does
> use 80bit values for temporaries.  The eon depends on roundoff errors
> and thus get slightly different results.
> The way to fix it is to ldpreload simple constructor that does set
> control word to 64bits like windows does.

  Ah!  I'll try specifying &#8722;mfpmath=sse2.  The default compile
environment on this box is "-m64 -cpu=k8".  When I specified "-m32" that
probably caused gcc to default to "-mcpu=i386".  My bad.  Thanks.  As soon as I
get a good run out I'll reply with a confirmation.  Sorry for the bogus email.

Casey

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

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

[Vladimir Makarov]

Casey Leedom wrote:
> 
> --- Joe Buck <jbuck@synopsys.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

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

[Casey Leedom]

  Okay, adding -fpmath=sse solved the problem.  Interestingly enough adding
"-march=k8 -mcpu=k8" wasn't good enough.  I would have thought that it would
have been from reading gcc/config/i386/i386.c:override_options() ...

Casey

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

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

[Jan Hubicka]

>   Okay, adding -fpmath=sse solved the problem.  Interestingly enough adding
> "-march=k8 -mcpu=k8" wasn't good enough.  I would have thought that it would
> have been from reading gcc/config/i386/i386.c:override_options() ...

We've been chatting about this with glibc folks and they don't like the
idea of losing the extra precisity 80bit temrporaries give, so
-mfpmath=sse can't be the default, unforutnately :(

Honza
> 
> Casey
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
> http://platinum.yahoo.com

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

[Jan Hubicka]

> Hi,
> 
>   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!

Also you may be interested in playing with hammer-3_3-branch GCC in case
you are interested in hammer performance. It is 3.3 GCC with some of
optimizations backported from mainline giving siginificantly better
results.  It is used at SuSE so it should be well tested for major
architectures.

At the moment mainline GCC still performs slightly better but the
difference is not too big.

Honza
> 
> Casey
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
> http://platinum.yahoo.com

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

[Casey Leedom]

/ Date: Fri, 28 Mar 2003 02:21:56 +0100
| From:"Jan Hubicka" <jh@suse.cz>
| 
| >   Okay, adding -fpmath=sse solved the problem.  Interestingly enough adding
| > "-march=k8 -mcpu=k8" wasn't good enough.  I would have thought that it
| > would have been from reading gcc/config/i386/i386.c:override_options() ...
| 
| We've been chatting about this with glibc folks and they don't like the
| idea of losing the extra precisity 80bit temrporaries give, so
\ -mfpmath=sse can't be the default, unforutnately :(

  Okay, I understand that.  So let me see if I'm 100% on the same page (I'm
very new to the x86 instruction set and it's history):

 1. x87 is a stack-based floating point co-processor (originally on a separate
    chip).  It performs calulations in 80-bit arithmetic for "double"s?

 2. SSE is a register-file floating point engine.  It was designed to support
    digital media applications and performs 64-bit arithmetic for "doubles"?

 3. SSE2 is an update of SSE that extends the arithmetic to use 128-bit
    (80-bit?) arithmetic for "doubles"?

I'm a bit confused because SPEC2000 252.eon fails with x87 in 32-bit mode but
succeeds with -mfpmath=sse in 32-bit mode.  Unfortunately, 301.apsi fails with
SSE in 32-bit mode.  And then of course, they all succeed in 64-bit mode which
defaults to SSE/SSE2 ...

  Which brings us to a different issue: the default math mode is dependent on
the 32- vs. 64-bit compilation mode rather than the fundamental CPU
architecture capabilities.  For instance, here's the relevant portion of
gcc/config/i386/i386.c:override_options():

  if (TARGET_64BIT)
    {
      if (TARGET_ALIGN_DOUBLE)
        error ("-malign-double makes no sense in the 64bit mode");
      if (TARGET_RTD)
        error ("-mrtd calling convention not supported in the 64bit mode");
      /* Enable by default the SSE and MMX builtins.  */
      target_flags |= (MASK_SSE2 | MASK_SSE | MASK_MMX |
MASK_128BIT_LONG_DOUBLE);
      ix86_fpmath = FPMATH_SSE;
     }
  else
    ix86_fpmath = FPMATH_387;

Worse yet, there's no way I can find to turn on SSE2 explicitly.  This is just
plain confusing and doesn't make sense.  If there are default math options that
vary by compilation, those defaults ought to be based on the target CPU
architecture, not the 32- vs. 64-bit compilation mode.


/ Date: Fri, 28 Mar 2003 12:35:22 +0100
| From:"Jan Hubicka" <jh@suse.cz>
| 
| Also you may be interested in playing with hammer-3_3-branch GCC in case
| you are interested in hammer performance. It is 3.3 GCC with some of
| optimizations backported from mainline giving siginificantly better
| results.  It is used at SuSE so it should be well tested for major
| architectures.
| 
| At the moment mainline GCC still performs slightly better but the
\ difference is not too big.

  I think that this is what we're playing with.  We got the rpm's from AMD ...

Casey

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

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

[Jan Hubicka]

> / Date: Fri, 28 Mar 2003 02:21:56 +0100
> | From:"Jan Hubicka" <jh@suse.cz>
> | 
> | >   Okay, adding -fpmath=sse solved the problem.  Interestingly enough adding
> | > "-march=k8 -mcpu=k8" wasn't good enough.  I would have thought that it
> | > would have been from reading gcc/config/i386/i386.c:override_options() ...
> | 
> | We've been chatting about this with glibc folks and they don't like the
> | idea of losing the extra precisity 80bit temrporaries give, so
> \ -mfpmath=sse can't be the default, unforutnately :(
> 
>   Okay, I understand that.  So let me see if I'm 100% on the same page (I'm
> very new to the x86 instruction set and it's history):
> 
>  1. x87 is a stack-based floating point co-processor (originally on a separate
>     chip).  It performs calulations in 80-bit arithmetic for "double"s?
> 
>  2. SSE is a register-file floating point engine.  It was designed to support
>     digital media applications and performs 64-bit arithmetic for "doubles"?
SSE does only "floats"
> 
>  3. SSE2 is an update of SSE that extends the arithmetic to use 128-bit
>     (80-bit?) arithmetic for "doubles"?
and SSE2 does doubles, 80-bit needs to be done in x87.
SSE can do 128bit operations on vector of 4 floats, SSE2 can deal with
vectors of 2 doubles.
> 
> I'm a bit confused because SPEC2000 252.eon fails with x87 in 32-bit mode but
> succeeds with -mfpmath=sse in 32-bit mode.  Unfortunately, 301.apsi fails with
> SSE in 32-bit mode.  And then of course, they all succeed in 64-bit mode which

This looks like a bug.  I am not testing 32bit SSE support too much, so
it is possible.  If you have idea what is getting wrong with it, it
would be helpfull - I am not particulary good on hunting bugs in fortran
code.
> defaults to SSE/SSE2 ...
> 
>   Which brings us to a different issue: the default math mode is dependent on
> the 32- vs. 64-bit compilation mode rather than the fundamental CPU
> architecture capabilities.  For instance, here's the relevant portion of
> gcc/config/i386/i386.c:override_options():

Yes, this is because the math is part of ABI (FLT_EVAL_METHOD)
at least according to the glibc people - the FLT_EVAL_METHOD is C99
thing and the PSABI is pre-C99 so it is not specified explicitly.
> 
>   if (TARGET_64BIT)
>     {
>       if (TARGET_ALIGN_DOUBLE)
>         error ("-malign-double makes no sense in the 64bit mode");
>       if (TARGET_RTD)
>         error ("-mrtd calling convention not supported in the 64bit mode");
>       /* Enable by default the SSE and MMX builtins.  */
>       target_flags |= (MASK_SSE2 | MASK_SSE | MASK_MMX |
> MASK_128BIT_LONG_DOUBLE);
>       ix86_fpmath = FPMATH_SSE;
>      }
>   else
>     ix86_fpmath = FPMATH_387;
> 
> Worse yet, there's no way I can find to turn on SSE2 explicitly.  This is just
> plain confusing and doesn't make sense.  If there are default math options that
> vary by compilation, those defaults ought to be based on the target CPU
> architecture, not the 32- vs. 64-bit compilation mode.

All these flags can be handled manually - you do have -msse/-msse2 and
-march switches to enable support for SSE/SSE2 instruction set
and you do have -mfpmath=sse to enable automatical generation of scalar
floating point in the SSE

To get same results in 32bit as for 64bit you need -msse2 -mfpmath=sse.

Honza

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

[Jan Hubicka]

> | 
> | At the moment mainline GCC still performs slightly better but the
> \ difference is not too big.
> 
>   I think that this is what we're playing with.  We got the rpm's from AMD ...

Then -march=k8 -mfpmath=sse should work fine for 32bit for you to get
SSE math.

Honza
> 
> Casey
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
> http://platinum.yahoo.com

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

[Andreas Jaeger]

Casey Leedom <casey_leedom@yahoo.com> writes:

> / Date: Fri, 28 Mar 2003 02:21:56 +0100
> | From:"Jan Hubicka" <jh@suse.cz>
> | 
> | >   Okay, adding -fpmath=sse solved the problem.  Interestingly enough adding
> | > "-march=k8 -mcpu=k8" wasn't good enough.  I would have thought that it
> | > would have been from reading gcc/config/i386/i386.c:override_options() ...
> | 
> | We've been chatting about this with glibc folks and they don't like the
> | idea of losing the extra precisity 80bit temrporaries give, so
> \ -mfpmath=sse can't be the default, unforutnately :(
>
>   Okay, I understand that.  So let me see if I'm 100% on the same page (I'm
> very new to the x86 instruction set and it's history):
>
>  1. x87 is a stack-based floating point co-processor (originally on a separate
>     chip).  It performs calulations in 80-bit arithmetic for "double"s?
>
>  2. SSE is a register-file floating point engine.  It was designed to support
>     digital media applications and performs 64-bit arithmetic for "doubles"?
>
>  3. SSE2 is an update of SSE that extends the arithmetic to use 128-bit
>     (80-bit?) arithmetic for "doubles"?

SSE and SSE2 together (don't remember what introduced what) have:
- 32-bit floats and performs 32-bit float arithmetic for these
- 64-bit doubles and performs 64-bit double arithmetic for these

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj