strtod rounding wrt. long double

[David Miller]

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!