bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mingw and isnanl


From: Bruno Haible
Subject: Re: mingw and isnanl
Date: Wed, 13 Jun 2007 02:08:20 +0200
User-agent: KMail/1.5.4

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





reply via email to

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