This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Increase internal precision of ldbl-128ibm decimal printf
- From: "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>
- To: Andreas Schwab <schwab at linux-m68k dot org>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>, Joseph Myers <joseph at codesourcery dot com>
- Date: Thu, 17 Mar 2016 17:40:19 -0500
- Subject: Re: [PATCH] Increase internal precision of ldbl-128ibm decimal printf
- Authentication-results: sourceware.org; auth=none
- References: <56EB246E dot 4050504 at linux dot vnet dot ibm dot com> <87bn6clqei dot fsf at linux-m68k dot org>
On 03/17/2016 04:56 PM, Andreas Schwab wrote:
> "Paul E. Murphy" <murphyp@linux.vnet.ibm.com> writes:
>
>> + /* Hold 7 extra bits of precision in the mantissa. This allows
>> + the normalizing shifts below to prevent losing precision when
>> + the signs differ and the exponents are sufficiently far apart. */
>> + lo <<= 7;
>
> That magical number should probably get a name.
Suggestions? It was noted as an "IEEE 854 adjustment" constant in
printf_fphex.c, and otherwise integrated into the shifts later on.
INTERNAL_PRECISION_SHIFT? Setting it 1 should fix the I case noted
in the comments.
>
>> /* we have a borrow from the hidden bit, so shift left 1. */
>> - hi = 0x0ffffffffffffeLL | (lo >> 51);
>> - lo = 0x1fffffffffffffLL & (lo << 1);
>> + hi = 0x000ffffffffffffeLL | (lo >> (52 + 7));
>> + lo = 0x0fffffffffffffffLL & (lo << 1);
>
> Not 51 + 7?
That is intentional. It should be moving the high bit of lo
lo into position 0. This is identical to how the ldbl-128ibm
printf_fphex.c, which does round trip these numbers correctly.
I.e ((1<<53)-1)>>51 == 3. The implicit bit is already factored
into lo, so the existing shift appears wrong here.
>
> Andreas.
>