This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> / Date: Fri, 28 Mar 2003 02:21:56 +0100
> | From:"Jan Hubicka" <jh at suse dot 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]