[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_ZERO         0x4000

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]