This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: strtod rounding wrt. long double
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: David Miller <davem at davemloft dot net>
- Cc: <libc-alpha at sourceware dot org>
- Date: Sat, 25 Jan 2014 18:03:59 +0000
- 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>
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