This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: mips SNaN/QNaN is swapped


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]