[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
## mingw and isnanl

**From**: |
Eric Blake |

**Subject**: |
mingw and isnanl |

**Date**: |
Tue, 12 Jun 2007 02:22:49 +0000 (UTC) |

**User-agent**: |
Loom/3.14 (http://gmane.org/) |

gnulib's test-isnanl currently dies on mingw, so we need to update the
configure test to account for the brokenness of the native isnanl.
fpclassify on mingw is documented to return only these five values:
#define FP_NAN 0x0100
#define FP_NORMAL 0x0400
#define FP_INFINITE (FP_NAN | FP_NORMAL)
#define FP_ZERO 0x4000
#define FP_SUBNORMAL (FP_NORMAL | FP_ZERO)
Using the five categories from test-isnanl.h:
pseudo-nan: LDBL80_WORDS (0xFFFF, 0x40000001, 0x00000000)
x==x:0 x!=x:1 x==0:0 fpclassify:0
pseudo-infinity: LDBL80_WORDS (0xFFFF, 0x00000000, 0x00000000)
x==x:0 x!=x:1 x==0:0 fpclassify:0
pseudo-zero: LDBL80_WORDS (0x4004, 0x00000000, 0x00000000)
x==x:0 x!=x:1 x==0:0 fpclassify:0
unnormalized normal: LDBL80_WORDS (0x4000, 0x63333333, 0x00000000)
x==x:0 x!=x:1 x==0:0 fpclassify:0
pseudo-denormal: LDBL80_WORDS (0x0000, 0x83333333, 0x00000000)
x==x:1 x!=x:0 x==0:0 fpclassify:4400
I think the test for isnanl is a bit harsh in insisting that all five invalid
long double categories be grouped as NaN, since the fifth category, pseudo-
denormal, appears to be recognized by the x86 hardware as a subnormal value.
However, for the first four categories, the fact that fpclassify returns an
undocumented value and that the hardware treats the value like NaN even though
mingw did not, shows that mingw needs to use the gnulib isnanl replacement.
And the fact that pseudo-zeros behave like NaN and not zero is just a
counterintuitive fact of x86 hardware that I'll have to get used to (before
last week, I was naive to the implications of the fact that Intel's extended
long double was only 64 bits, not 65 bits, of mantissa).
--
Eric Blake

**mingw and isnanl**,
*Eric Blake* **<=**