[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign

["joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446

--- Comment #14 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-12-08 22:32:24 UTC ---
On Thu, 8 Dec 2011, lucier at math dot purdue.edu wrote:

> Indeed, I couldn't find a place in the gcc sources where this macro was
> used:
> 
> heine:~/programs/gcc/mainline> grep -R _FP_NANSIGN_Q * | grep -v svn

It's used as _FP_NANSIGN_##fs.

> > At the level of GCC compiling C code, the compiler provides the language 
> > semantics.  It doesn't provide the semantics of any particular choice of 
> > instructions someone might expect to be used to implement the source code 
> > - and in particular doesn't guarantee any choice of NaN where the language 
> > (and IEEE 754 as applicable) don't determine the choice of NaN.
> 
> I don't think the result of 0./0. in C code on a particular target
> should depend on telling the compiler that the runtime library is set up
> so that floating-point operations never trap.

This is just the same as other unspecified things like converting an 
out-of-range value from floating-point to integer.  There is no C language 
binding to the processor that defines the result of a/b as being the 
result of some particular divide instruction (and it's quite likely that 
on some processors the choice of NaN could depend e.g. on whether a scalar 
or vector instruction is used); it's only specified as far as the 
language specifies it.  This also allows transformations such as 
converting -1.0*x to -x even if -1.0*x doesn't change the sign of an input 
NaN (negate *is* specified by 754-2008 to change the sign of a NaN).