diff options
author | Alan Modra <amodra@gmail.com> | 2013-08-17 18:19:44 +0930 |
---|---|---|
committer | Alan Modra <amodra@gmail.com> | 2013-10-04 10:30:56 +0930 |
commit | 4cf69995e26e16005d4e3843ad4d18c75cf21a04 (patch) | |
tree | c4e7626b3327a4599c289ffef71bdeba16292b25 /sysdeps/ieee754/ldbl-128ibm/e_rem_pio2l.c | |
parent | 9605ca6c085a749f29b6866a3e00bce1ba1a2698 (diff) | |
download | glibc-4cf69995e26e16005d4e3843ad4d18c75cf21a04.tar.gz glibc-4cf69995e26e16005d4e3843ad4d18c75cf21a04.tar.xz glibc-4cf69995e26e16005d4e3843ad4d18c75cf21a04.zip |
Fix for [BZ #15680] IBM long double inaccuracy
http://sourceware.org/ml/libc-alpha/2013-06/msg00919.html I discovered a number of places where denormals and other corner cases were being handled wrongly. - printf_fphex.c: Testing for the low double exponent being zero is unnecessary. If the difference in exponents is less than 53 then the high double exponent must be nearing the low end of its range, and the low double exponent hit rock bottom. - ldbl2mpn.c: A denormal (ie. exponent of zero) value is treated as if the exponent was one, so shift mantissa left by one. Code handling normalisation of the low double mantissa lacked a test for shift count greater than bits in type being shifted, and lacked anything to handle the case where the difference in exponents is less than 53 as in printf_fphex.c. - math_ldbl.h (ldbl_extract_mantissa): Same as above, but worse, with code testing for exponent > 1 for some reason, probably a typo for >= 1. - math_ldbl.h (ldbl_insert_mantissa): Round the high double as per mpn2ldbl.c (hi is odd or explicit mantissas non-zero) so that the number we return won't change when applying ldbl_canonicalize(). Add missing overflow checks and normalisation of high mantissa. Correct misleading comment: "The hidden bit of the lo mantissa is zero" is not always true as can be seen from the code rounding the hi mantissa. Also by inspection, lzcount can never be less than zero so remove that test. Lastly, masking bitfields to their widths can be left to the compiler. - mpn2ldbl.c: The overflow checks here on rounding of high double were just plain wrong. Incrementing the exponent must be accompanied by a shift right of the mantissa to keep the value unchanged. Above notes for ldbl_insert_mantissa are also relevant. [BZ #15680] * sysdeps/ieee754/ldbl-128ibm/e_rem_pio2l.c: Comment fix. * sysdeps/ieee754/ldbl-128ibm/printf_fphex.c (PRINT_FPHEX_LONG_DOUBLE): Tidy code by moving -53 into ediff calculation. Remove unnecessary test for denormal exponent. * sysdeps/ieee754/ldbl-128ibm/ldbl2mpn.c (__mpn_extract_long_double): Correct handling of denormals. Avoid undefined shift behaviour. Correct normalisation of low mantissa when low double is denormal. * sysdeps/ieee754/ldbl-128ibm/math_ldbl.h (ldbl_extract_mantissa): Likewise. Comment. Use uint64_t* for hi64. (ldbl_insert_mantissa): Make both hi64 and lo64 parms uint64_t. Correct normalisation of low mantissa. Test for overflow of high mantissa and normalise. (ldbl_nearbyint): Use more readable constant for two52. * sysdeps/ieee754/ldbl-128ibm/mpn2ldbl.c (__mpn_construct_long_double): Fix test for overflow of high mantissa and correct normalisation. Avoid undefined shift.
Diffstat (limited to 'sysdeps/ieee754/ldbl-128ibm/e_rem_pio2l.c')
-rw-r--r-- | sysdeps/ieee754/ldbl-128ibm/e_rem_pio2l.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/sysdeps/ieee754/ldbl-128ibm/e_rem_pio2l.c b/sysdeps/ieee754/ldbl-128ibm/e_rem_pio2l.c index 6a72d6a853..8885def4e1 100644 --- a/sysdeps/ieee754/ldbl-128ibm/e_rem_pio2l.c +++ b/sysdeps/ieee754/ldbl-128ibm/e_rem_pio2l.c @@ -243,7 +243,7 @@ int32_t __ieee754_rem_pio2l(long double x, long double *y) We split the 113 bits of the mantissa into 5 24bit integers stored in a double array. */ /* Make the IBM extended format 105 bit mantissa look like the ieee854 112 - bit mantissa so the next operatation will give the correct result. */ + bit mantissa so the next operation will give the correct result. */ ldbl_extract_mantissa (&ixd, &lxd, &exp, x); exp = exp - 23; /* This is faster than doing this in floating point, because we |