mingw and isnanl

[Eric Blake]

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