Re: [RFC][PATCH] MIPS: IEEE 754-2008 NaN encoding support

[Rich Felker <dalias@aerifal.cx>]

On Thu, Aug 22, 2013 at 08:10:49PM -0700, pinskia@gmail.com wrote:
> >> To give you a small example this:
> >> 
> >> double foo = __builtin_nan ("");
> >> 
> >> will compile to a different data pattern with opposite (qNaN vs sNaN) 
> >> semantics depending on the NaN encoding mode selected in the compiler.  
> >> Modules built with different NaN encodings are therefore not compatible,
> > 
> > They are compatible except in the area of subtle exception-raising
> > semantics that GCC *DOES NOT GET CORRECT ANYWAY*. GCC is full of
> > incorrect optimizations that cause the exception flags to be wrong.
> > Until that's fixed, I don't see why this issue is so important to
> > merit flagging object files build with different modes as having an
> > incompatible ABI. The semantics are slightly different, but the type
> > sizes and the way they're passed are all the same, and programs that
> > don't use the GCC extension __builtin_nan() or the NAN macro from
> > math.h, or writing raw float values to/from disk, are completely
> > unaffected.
> 
> Can you give an example and maybe a link to a GCC bug where this is
> recorded before spreading this kind of information. I really don't
> like blank statements without facts to back up them.

int foo() { double x = 0; x /= 0.0; return 1; }

While this is a stupid, trivial example, the issue has come up A LOT
for us in musl's implementation of the math library (based on fdlibm)
with nontrivial code.

Rich