public inbox for
 help / color / mirror / Atom feed
To: Rich Felker <>
Cc: "Maciej W. Rozycki" <>,
	"" <>,
	"" <>,
	Doug Gilmore <>
Subject: Re: [RFC][PATCH] MIPS: IEEE 754-2008 NaN encoding support
Date: Fri, 23 Aug 2013 03:11:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Aug 22, 2013, at 6:57 PM, Rich Felker <> 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.

Andrew Pinski

>> either at the link or at the load time, as applicable.  LD (from binutils) 
>> and 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

  reply	other threads:[~2013-08-23  3:11 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-22 23:53 Maciej W. Rozycki
2013-08-23  0:58 ` Rich Felker
2013-08-23  1:41   ` Maciej W. Rozycki
2013-08-23  1:57     ` Rich Felker
2013-08-23  3:11       ` pinskia [this message]
2013-08-23  3:38         ` Rich Felker
2013-08-23  4:08           ` pinskia
2013-08-23  4:12             ` Rich Felker
2013-08-23  4:10     ` Rich Felker
2013-08-23  3:46 ` Rich Felker
2013-08-23 10:53   ` Maciej W. Rozycki
2013-08-23 15:26 ` Joseph S. Myers
2013-09-05 22:47   ` [RFC][PATCH v2] " Maciej W. Rozycki
2013-09-06 16:24     ` Joseph S. Myers
2013-09-10  9:36       ` Maciej W. Rozycki
2013-09-10 23:24         ` Joseph S. Myers
2013-09-16 15:14           ` [PATCH v3] " Maciej W. Rozycki
2013-09-16 15:26             ` Joseph S. Myers
2013-09-18 20:48               ` Maciej W. Rozycki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).