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
