This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: QNaN and SNaN definitions
- From: "H . J . Lu" <hjl at lucon dot org>
- To: Hartvig Ekner <hartvige at mips dot com>
- Cc: libc-alpha at sources dot redhat dot com
- Date: Tue, 19 Mar 2002 13:42:25 -0800
- Subject: Re: QNaN and SNaN definitions
- References: <200203192134.g2JLYB403233@coplin09.mips.com>
On Tue, Mar 19, 2002 at 10:34:11PM +0100, Hartvig Ekner wrote:
> I have found the glibc definitions for QNaN and SNaN are wrong for MIPS
> (and some other architectures).
>
> Unfortunately, IEEE let it up to the implementations to decide how
> the bit distinguishing between QNaN and SNaN was to be encoded, and
> most of the world choose that particular bit==1 to mean QNaN.
>
> For MIPS, HPPA and maybe others, that bit is reversed, and has to be ==0
> to mean QNaN.
>
> As far as I can see, all cases inside glibc don't care whether things
> are a QNaN or SNaN (eg. isnan(), fpclassify etc) and therefore work
> correctly for both cases, but some of the public header files in glibc
> which end up in /usr/include are wrong:
>
> sysdeps/ieee754/bits/nan.h
>
> Specifically specifies a NaN (QNaN) to 7fc0.0000.
>
> sysdeps/ieee754/ieee754.h:
>
> Defines 8 structures like:
>
> /* This format makes it easier to see if a NaN is a signalling NaN. */
> struct
> {
> #if __BYTE_ORDER == __BIG_ENDIAN
> unsigned int negative:1;
> unsigned int exponent:8;
> unsigned int quiet_nan:1;
> unsigned int mantissa:22;
>
> I can send in patches to fix this for MIPS, but I would think this is
> inappropriate and that some of you glibc people would have to decide how
> to deal with this. If you can tell me how you want it fixed, I will be
> happy to deliver the patches, but I need a machine specific #define to
> look at in these header files. I would like to avoid separate MIPS versions
> of these header files if possible (maintenance issues).
Just create a new sysdeps/mips/bits/nan.h with the right bits.
>
> In nan.h, it is clear what has to be done.
>
> In ieee754.h it is less clear. One can leave things as they are, but then
> peoples apps will not work without them knowing the difference. Maybe define
> machine-dep constants to be used with the quiet_nan field, or more
> drastically, rename the quiet_nan field to signalling_nan. Is this an
> option at all?
>
You can create a new sysdeps/mips/ieee754.h and change quiet_nan to
signalling_nan. Any codes depending on quiet_nan will fail on mips
H.J.