This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: [RFC][PATCH] MIPS: IEEE 754-2008 NaN encoding support
- From: Rich Felker <dalias at aerifal dot cx>
- To: pinskia at gmail dot com
- 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: Fri, 23 Aug 2013 00:12:22 -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> <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> <FF67A97D-0C17-4613-BAEB-89F00BFA5B4F at gmail dot com> <20130823033802 dot GO20515 at brightrain dot aerifal dot cx> <6DDE6A09-5E4D-4FCF-B126-7021735F431F at gmail dot com>
On Thu, Aug 22, 2013 at 09:07:34PM -0700, pinskia@gmail.com wrote:
> On Aug 22, 2013, at 8:38 PM, Rich Felker <dalias@aerifal.cx> wrote:
>
> > On Thu, Aug 22, 2013 at 08:10:49PM -0700, pinskia@gmail.com wrote:
> >>>> 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.
> >
> > int foo() { double x = 0; x /= 0.0; return 1; }
> >
> > While this is a stupid, trivial example, the issue has come up A LOT
> > for us in musl's implementation of the math library (based on fdlibm)
> > with nontrivial code.
>
> Wait you mean dead code? I think the standard/IEEE allows to remove
> it.
They don't. Anyway, here's a less trivial example:
double f(int y){ double x=0; x/=0; if(y) return 1; return x; }
> At -O0, GCC won't remove it though.
That's not helpful; -O0 is not usable for most purposes. The output is
gigantic and slow. And if I'm not mistaken, there are some cases where
even -O0 will mess it up...
Rich