This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: strtod rounding wrt. long double
- From: David Miller <davem at davemloft dot net>
- To: joseph at codesourcery dot com
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 27 Jan 2014 16:51:36 -0800 (PST)
- Subject: Re: strtod rounding wrt. long double
- Authentication-results: sourceware.org; auth=none
- References: <20140124 dot 183042 dot 2275733120832804149 dot davem at davemloft dot net> <Pine dot LNX dot 4 dot 64 dot 1401251801200 dot 11772 at digraph dot polyomino dot org dot uk>
From: "Joseph S. Myers" <joseph@codesourcery.com>
Date: Sat, 25 Jan 2014 18:03:59 +0000
> On Fri, 24 Jan 2014, David Miller wrote:
>
>> While regenerating the ULPs for sparc, I noticed that I get failures
>> for tst-strtod-round of the form:
>>
>> strtold (0x1p-16446) returned 0x0.000000000000000100000001p-16382 not 0x0.0000000000000001p-16382 (default rounding mode)
>> strtold (0x1p-16446) returned 0x0.000000000000000100000001p-16382 not 0x0.0000000000000001p-16382 (FE_DOWNWARD)
>> strtold (0x1p-16446) returned 0x0.000000000000000100000001p-16382 not 0x0.0000000000000001p-16382 (FE_TOWARDZERO)
>> strtold (0x1p-16446) returned 0x0.000000000000000100000001p-16382 not 0x0.0000000000000001p-16382 (FE_UPWARD)
>> strtold (-0x1p-16446) returned -0x0.000000000000000100000001p-16382 not -0x0.0000000000000001p-16382 (default rounding mode)
>> strtold (-0x1p-16446) returned -0x0.000000000000000100000001p-16382 not -0x0.0000000000000001p-16382 (FE_DOWNWARD)
>> strtold (-0x1p-16446) returned -0x0.000000000000000100000001p-16382 not -0x0.0000000000000001p-16382 (FE_TOWARDZERO)
>> strtold (-0x1p-16446) returned -0x0.000000000000000100000001p-16382 not -0x0.0000000000000001p-16382 (FE_UPWARD)
>>
>> Does this look like a test error or is this more likely some sparc
>> specific bug in the long double routines?
>
> That sounds like some sparc-specific bug in strtold or one of the
> functions it calls (you don't say whether this appears for 32-bit, 64-bit
> or both). I'd suggest first seeing if the computed number as passed to
> round_and_return is correct, then whether the rounded (i.e. just shifted
> right in this case, as an exact subnormal value) value passed to
> __mpn_construct_long_double is correct.
It only fails for 32-bit. I'll try reverting the 32-bit v9 optimized
mpn routines and see if those are the culprit.
Thanks!