QNaN and SNaN definitions

[Andreas Jaeger]

Hartvig Ekner <hartvige@mips.com> writes:

> H . J . Lu writes:
>> 
>> On Wed, Mar 20, 2002 at 10:28:14PM +0100, Hartvig Ekner wrote:
>> > 
>> > I would really like to avoid especially ieee754 branching off into a 
>> > separate MIPS file, since it contains a lot of other stuff than the
>> > quiet_nan thing.
>> > 
>> 
>> # find sysdeps  -name ieee754.h
>> sysdeps/arm/ieee754.h
>> sysdeps/ia64/ieee754.h
>> sysdeps/ieee754/ieee754.h
>> sysdeps/ieee754/ldbl-128/ieee754.h
>> sysdeps/sparc/sparc32/ieee754.h
>> 
>> MIPS is not alone. Just add
>> 
>> sysdeps/mips/ieee754.h
>> sysdeps/mips/bits/nan.h
>> 
>> MIPS should be fine.
>> 
>> 
>> H.J.
>
> I rest my case for nan.h, a separate file will work nicely :-)
>
> However, what should I do in a separate ieee754.h file for MIPS? 
> Rename the quiet_nan field? Add the constants proposed in my patch?
>
> All of this is fine and good, but does not allow writing of portable
> apps (without using #ifdef mips) which use the ieee754.h quiet_nan fields,
> unless we also include the bit values for the quiet_nan field
> corresponding to quiet/signalling NaNs in all versions of the ieee754.h
> header files.

grep -r quiet_nan in glibc reveals that quiet_nan is not used
anywhere.  The header just describes the status.  So, for glibc
there's no problem with renaming that entry.

> I'm not sure how to read Ulrichs comment on the generic ieee754.h file,
> whether no mips #ifdefs are acceptable, or no changes whatsoever.

Let me interpret him: #ifdef mips is always wrong.

A new mips-specific ieee754.h file is fine,

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj