[Bug libc/5268] huge and denornal reads and writes for long doubles

["amodra at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=5268

Alan Modra <amodra at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amodra at gmail dot com

--- Comment #3 from Alan Modra <amodra at gmail dot com> ---
huge() seems to give a long double having component doubles of 0x1p+1023
-0x1p+917.  I'm not sure why this value is chosen, as it's quite a lot smaller
than the largest correctly rounded long double not an infinity.  It's even
smaller than the value returned by huge() for double!  And it's really really
odd that the low double is negative..

The actual maximum is 0x1.fffffffffffff7ffffffffffffcp+1023 (component doubles
of 0x1.fffffffffffffp+1023 0x1.fffffffffffffp+969).  That "7" is there because
anything higher will cause the high double to be rounded to inf.

As to the bug with writing out the current huge() and reading back in, I think
you'll find the problem is related to normalisation in
sysdeps/ieee754/ldbl-128ibm/ldbl2mpn.c where the mantissa is trimmed to 105
bits.  The current huge() has exponents that differ by 106.  That means there
are 53 implicit bits of significand between the high double significand and the
low double significand.
So the number you're trying to write is actually
0x1.ffffffffffffffffffffffffff8p+1022 (if I can count) which ought to be OK. 
However, ldbl2mpn.c normalises before subtracting, resulting in the low double
mantissa becoming zero.  Net result is loss of one bit.  This bug isn't
addressed by http://sourceware.org/ml/libc-alpha/2013-06/msg00919.html.

-- 
You are receiving this mail because:
You are on the CC list for the bug.