This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: mips SNaN/QNaN is swapped
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: cgd at broadcom dot com, gcc-patches at gcc dot gnu dot org, Richard dot Earnshaw at arm dot com
- Date: Tue, 25 Mar 2003 10:44:49 +0000
- Subject: Re: mips SNaN/QNaN is swapped
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> On Mar 24, 2003, cgd at broadcom dot com wrote:
>
> > At Mon, 24 Mar 2003 04:36:25 +0000 (UTC), "Alexandre Oliva" wrote:
> >> mips doesn't cease to surprise me in its floating-point formats.
> >> Contrary to the IEEE 754 specifications, the bit that is traditionally
> >> used to flag a quiet NaN is used to mark a signaling NaN on mips.
>
> > Uh, i couldn't find anything in IEEE 754 or 854 about requirements on
> > the values of NaNs (specifically which are quiet and which are
> > signalling)
>
> I stand corrected. I must admit I just assumed that to be the case
> because every other IEEE-compliant FPU I've seen before did it that
> way. In fact, when I got the report from you, I recalled having heard
> something along the lines of `MIPS FPU is non-standard', which was
> probably meant as `different from everything else', not `not compliant
> with IEEE 754', which was how I understood it.
>
Indeed. IEEE 754 simply says that there will be at least on SNaN and at
least one QNaN, but it doesn't say anything else (most helpful, not).
Maybe we should have __builtin_snan() and __builtin_qnan() to give us one
of each on a per-machine basis. Clearly, it isn't possible to portably
generate these with the existing __builtin_nan() function.
R.