This is the mail archive of the
mailing list for the glibc project.
Re: [RFC][PATCH] MIPS: IEEE 754-2008 NaN encoding support
- From: pinskia at gmail dot com
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: "Maciej W. Rozycki" <macro at codesourcery dot com>, "libc-ports at sourceware dot org" <libc-ports at sourceware dot org>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, Doug Gilmore <Doug dot Gilmore at imgtec dot com>
- Date: Thu, 22 Aug 2013 20:10:49 -0700
- Subject: Re: [RFC][PATCH] MIPS: IEEE 754-2008 NaN encoding support
- References: <alpine dot DEB dot 1 dot 10 dot 1308222343480 dot 8514 at tp dot orcam dot me dot uk> <20130823005820 dot GL20515 at brightrain dot aerifal dot cx> <alpine dot DEB dot 1 dot 10 dot 1308230213040 dot 8514 at tp dot orcam dot me dot uk> <20130823015727 dot GM20515 at brightrain dot aerifal dot cx>
On Aug 22, 2013, at 6:57 PM, Rich Felker <email@example.com> 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  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
>>>> As from revision 3.50  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
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.
>> 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,
>> 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)...