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
