This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: IBM long double fixes
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Alan Modra <amodra at gmail dot com>
- Cc: Andreas Schwab <schwab at suse dot de>, <libc-alpha at sourceware dot org>, Steve Munroe <sjmunroe at us dot ibm dot com>, Ryan Arnold <ryanarn at us dot ibm dot com>
- Date: Mon, 1 Jul 2013 22:21:30 +0000
- Subject: Re: IBM long double fixes
- References: <20130625063840 dot GK21523 at bubble dot grove dot modra dot org> <mvmy59yps96 dot fsf at hawking dot suse dot de> <20130625114529 dot GM21523 at bubble dot grove dot modra dot org>
On Tue, 25 Jun 2013, Alan Modra wrote:
> And here are the bug fixes.
> Refer http://sourceware.org/ml/libc-alpha/2013-06/msg00914.html
>
> * 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.
These fixes seem OK to me, although again I think Ryan should look at
them. I would note:
* It's not clear there is any real need for code to check the exponent
difference is at least 53 and do something different if it isn't, given
that a difference of less than 53 means an invalid long double value (i.e.
a trap representation in ISO C terms). There have been previously
rejected bug reports (bug 4586 at least) for crashes on passing invalid
ldbl-96 values to standard library functions. I don't object to including
such checks, but there is at least no consensus that there is any need for
them. (This does raise the question of what the DTS 18661-1 iscanonical
and canonicalize should do for such representations if we implement those
macros / functions; I'm inclined to think they should check for and handle
the invalid values even if other functions don't.)
> static inline double
> ldbl_nearbyint (double a)
> {
> - double two52 = 0x10000000000000LL;
> + double two52 = (uint64_t) 1 << 52;
I think 0x1p52 is better than either of these variants (generally, in such
cases it's appropriate to use hex floats).
--
Joseph S. Myers
joseph@codesourcery.com