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

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

> 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)...


  reply	other threads:[~2013-08-23  1:57 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 [this message]
2013-08-23  3:11       ` pinskia
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).