[RFC][PATCH] MIPS: IEEE 754-2008 NaN encoding support
pinskia@gmail.com
pinskia@gmail.com
Fri Aug 23 04:08:00 GMT 2013
On Aug 22, 2013, at 8:38 PM, Rich Felker <dalias@aerifal.cx> wrote:
> 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.
Wait you mean dead code? I think the standard/IEEE allows to remove it. At -O0, GCC won't remove it though.
>
> Rich
More information about the Libc-ports
mailing list