Eric Blake wrote:
> gnulib's test-isnanl currently dies on mingw
I don't observe this. Just did a
./gnulib-tool --create-megatestdir --dir=/dev/shm/testdir1 --with-tests \
isnan-nolibm isnanl-nolibm isnanl vasnprintf-posix
configured it on mingw (msys), and all tests pass. Notice the line
checking whether isnanl works... no
> so we need to update the
> configure test to account for the brokenness of the native isnanl.
m4/isnanl.m4 was already updated on 2007-06-05.
> 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.
The key word in this sentence is "appears". You tested some operations on
a particular CPU from one vendor. But this area is outside of IEEE 754
specifications, and hardly stressed by software (which is why the glibc
crash could stay for so long). You don't know how, say, the hardware 'fsin'
instruction groks pseudo-zeros.
At this point I think the porting trouble is not worth any more the win.
Bruno
