This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC][PATCH] MIPS: IEEE 754-2008 NaN encoding support
- From: Rich Felker <dalias at aerifal dot cx>
- To: "Maciej W. Rozycki" <macro at codesourcery dot com>
- Cc: libc-ports 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:58:20 -0400
- 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>
On Fri, Aug 23, 2013 at 12:52:43AM +0100, Maciej W. Rozycki 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.
Rich