On Mar 25 18:16, Doug Henderson wrote:
> On 25 March 2016 at 02:59, Achim Gratz <Stromeko@nexgo.de> wrote:
> >
> > Achim Gratz writes:
> > > Achim Gratz writes:
> > >> Long story short, they seem to report a finite value on at least some
> > >> NaN constructs and then the %a format for the Perl sprintf outputs those
> > >> bits as a hex FP number rather than just printing "NaN".  On 64bit the
> > >> culprit is actually finitel, of course, since Perl gets compiled with
> > >> long doubles.
> > >
> > > And looking into newlib this seems to be a compile bug, because the
> > > function just uses an intrinsic.
> >
> > But the compiler is innocent, because newlib uses the wrong intrinsic or
> > an incomplete implementation.  If it must be using that intrinsic for
> > compatibility reasons, it would need to implement
> >
> > <snip>
> >
> > Regards,
> > Achim.
> >
> 
> 
> I modified your program to display the actual hex value of the a, b,
> and c variables. The b and c variables have different bit patterns. It
> appears that the %a format conversion is (correctly) detecting ±inf
> and NaN according to IEEE 754, and ignoring the value of all other
> bits in the variables.
> 
> It appears that strtold and the implicit conversion from double to
> long double are setting some of the bits which are not used to
> represent NaN or ±Inf to different values.

strtold actually forgot to set one bit.

I now fixed finitel, the return value of strtold for +/-infinity,
and I improved math.h by using GCC builtins for the C99 macros
which makes them type agnostic and thus lon double aware.

Building a snaphot right now.  Please give it a try.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat