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).
