bug-gnulib
[Top][All Lists]
Advanced

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

Re: mingw and isnanl


From: Eric Blake
Subject: Re: mingw and isnanl
Date: Wed, 13 Jun 2007 00:52:05 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

Bruno Haible <bruno <at> clisp.org> writes:

> 
> 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

The problem is not a native compile, but a cross-compile, which merely assumes 
that because isnanl exists, it works.

configure:15398: checking whether isnanl works
configure:15550: result: guessing yes

> 
> > 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.

but currently only rejects cross-compiles to netbsd.  I guess my original 
complaint should have made that more explicit.

> 
> 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.

Fair enough, I like your argument (as it is, when debugging these invalid bit 
patterns for long double, gdb merely prints <invalid float value> for all five 
categories rather than printing anything resembling the output of a valid 
corresponding 754 counterpart, or even trying to distinguish categories among 
the invalid values).  I am trying to find time to implement isnanl, frexpl, and 
a couple other long double primitives in newlib (without them, CVS cygwin's 
printf("%La") will crash on finite long doubles that are no longer finite when 
converted to double), so I will make sure that they treat all non-754 formats 
as NaN.  Cygwin licensing issues prevent the direct inclusion of gnulib code, 
so it has to be implemented from scratch, but you can bet that I'm using your 
test cases as clues to whether my implementation conforms.

-- 
Eric Blake






reply via email to

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