GCC beaten by ICC in stupid trig test!

[Joseph S. Myers]

On Wed, 24 Mar 2004, Joe Buck wrote:

> So: does this mean that a conforming C compiler is not permitted, for
> 
> double add(double a, double b, double c) { return a + b + c;}
> 
> to generate the equivalent of
> 
>    double t1 = a + c;
>    return t1 + b;
> 
> as a Fortran compiler is?

Not if it defines __STDC_IEC_559__.  Otherwise, 5.2.4.2.2#4 states that
the implementation may state that the accuracy of floating-point
operations is unknown.

-ffast-math isn't necessarily intended as a mode that conforms even to ISO
C, but clearly most of the component flags should disable __STDC_IEC_559__
(except -fno-math-errno, where math_errhandling should take on whatever
value is consistent with all translation units in the program,
-fno-rounding-math (default), since this should only determine the
FENV_ACCESS default, and -fno-signaling-nans (default), since ISO C
doesn't support signaling NaNs).  (The default of CX_LIMITED_RANGE is
meant to be "off".  We only implement "on", but if the pragma ever gets
implemented then I expect -ffast-math would also make the default be the
nonconforming "on".)

GCC doesn't define __STDC_IEC_559__.  Glibc does, unconditionally.  This
is broken since (a) it must be constant throughout the translation unit,
regardless of inclusion of standard headers, (b) it should be disabled by
any one of -funsafe-math-optimizations, -ffinite-math-only and
-fno-trapping-math (but we don't have predefined macros for all the
separate flags in -ffast-math to let glibc do this - we should).

-- 
Joseph S. Myers
jsm@polyomino.org.uk