This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: SPEC2000 252.eon generates invalid results when compiled -O3 with g++ 3.3
- From: Jan Hubicka <jh at suse dot cz>
- To: Casey Leedom <casey_leedom at yahoo dot com>
- Cc: Jan Hubicka <jh at suse dot cz>, Joe Buck <jbuck at synopsys dot com>,dann at godzilla dot ics dot uci dot edu, mark at codesourcery dot com, gcc at gcc dot gnu dot org,dan at dberlin dot org, aj at suse dot de
- Date: Sat, 29 Mar 2003 00:46:52 +0100
- Subject: Re: SPEC2000 252.eon generates invalid results when compiled -O3 with g++ 3.3
- References: <20030328012156.GA10149@kam.mff.cuni.cz> <20030328214304.47039.qmail@web13104.mail.yahoo.com>
> / 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