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

[pinskia@gmail.com]

On Aug 22, 2013, at 6:57 PM, Rich Felker <dalias@aerifal.cx> wrote:

> On Fri, Aug 23, 2013 at 02:41:21AM +0100, Maciej W. Rozycki wrote:
>> On Fri, 23 Aug 2013, Rich Felker wrote:
>> 
>>>> As many of you have been aware it has been a long practice for software 
>>>> using IEEE 754 floating-point arithmetic run on MIPS processors to use an 
>>>> encoding of Not-a-Number (NaN) data different to one used by software run 
>>>> on other processors.  And as of IEEE 754-2008 revision [1] this encoding 
>>>> does not follow one recommended in the standard, as specified in section 
>>>> 6.2.1, where it is stated that quiet NaNs should have the first bit (d1) 
>>>> of their significand set to 1 while signalling NaNs should have that bit 
>>>> set to 0, but MIPS software interprets the two bits in the opposite 
>>>> manner.
>>>> 
>>>> As from revision 3.50 [2][3] the MIPS Architecture provides for 
>>>> processors that support the IEEE 754-2008 preferred NaN encoding format.  
>>>> As the two formats (further referred to as "legacy NaN" and "2008 NaN") 
>>>> are incompatible to each other, tools will have to provide support for the 
>>>> two formats to help people avoid using incompatible binary modules.  Here 
>>>> is the glibc part.
>>> 
>>> Can you elaborate on why you think this is an ABI issue? IMO it's just
>>> s runtime issue unless you're considering raw floating point data
>>> written to disk. In any case this seems like such a small issue that
>>> it should just be silently fixed, rather than adding huge amounts of
>>> ABI ugliness.
>> 
>> 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.

Thanks,
Andrew Pinski


> 
>> either at the link or at the load time, as applicable.  LD (from binutils) 
>> and ld.so take care of the link-time and the load-time integrity check, 
>> respectively.
>> 
>> Additionally hardware has to be configured to match the encoding selected 
>> and executables that require a NaN encoding that is not supported by a 
>> given piece of hardware have to be rejected -- execve(2) is supposed to 
>> return in that case, which may only be handled by the kernel.  Please note 
>> that neither the legacy-NaN nor the 2008-NaN encoding is mandatory in the 
>> MIPS architecture; MIPS FPU hardware at the implementer's discretion may 
>> support either or both.
>> 
>> I hope this answers your question.  Any further concerns?
> 
> I'm just opposed to introducing massive complexity and spurious linker
> errors for the sake of something that shouldn't affect most programs,
> and where the only affected programs already had wrong behavior due to
> GCC's lack of proper support for floating point exception and
> rounding-mode semantics. Signaling NANs are an obscure, optional
> feature almost nobody uses, and if you're not intentionally using
> them, you don't care if computations with NANs raise spurious
> exceptions or not (especially since the exception was already raised
> when you first generated the NAN, unless you loaded a NAN explicitly
> via the NAN macro or strtod("NAN", 0)...
> 
> Rich