strtod rounding wrt. long double

[Joseph S. Myers]

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.

-- 
Joseph S. Myers
joseph@codesourcery.com