This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug math/19071] ldbl-96 lroundl incorrect just below powers of 2
- From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 05 Oct 2015 22:56:00 +0000
- Subject: [Bug math/19071] ldbl-96 lroundl incorrect just below powers of 2
- Auto-submitted: auto-generated
- References: <bug-19071-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=19071
--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".
The branch, master has been updated
via cec7d28af8ccb40dbf82d99efa13a040b31b9387 (commit)
from a8133e197ec852cac46132efeeefae14489031f0 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=cec7d28af8ccb40dbf82d99efa13a040b31b9387
commit cec7d28af8ccb40dbf82d99efa13a040b31b9387
Author: Joseph Myers <joseph@codesourcery.com>
Date: Mon Oct 5 22:53:50 2015 +0000
Fix ldbl-96 lroundl just below powers of 2 (bug 19071).
The ldbl-96 version of lroundl is incorrect for systems with 64-bit
long when the argument's absolute value is just below a power of 2,
2^32 or more, and rounds up to the next integer; in such cases, it
returns 0. The problem is incrementing the high part of the mantissa
loses the high bit of the value (which is not an issue for any other
floating-point format, and is handled specially in lround when the bit
corresponding to 0.5 was in the high part rather than the low part).
This patch fixes this in a similar way to that used in llroundl:
storing the high part in an unsigned long variable before incrementing
it, so problems cannot occur in the case when this code is reachable.
I improved test coverage for both lround and llround by making them
use the same test inputs (appropriately conditioned on the size of
long in the lround case) - complete with the same comments, to make
comparison as easy as possible. (This test coverage improvement was
how I found the lroundl bug.)
Tested for x86_64 and x86.
[BZ #19071]
* sysdeps/ieee754/ldbl-96/s_lroundl.c (__lroundl): Use unsigned
long int variable to store possibly incremented high part of
mantissa.
* math/libm-test.inc (lround_test_data): Add tests used for
llround. Use [LONG_MAX > 0x7fffffff] consistently as condition
for tests requiring 64-bit long. Do not condition tests on
[TEST_FLOAT] unnecessarily.
(llround_test_data): Add tests used for lround. Add another
expectation for the "inexact" exception. Do not condition tests
on [TEST_FLOAT] unnecessarily.
-----------------------------------------------------------------------
Summary of changes:
ChangeLog | 12 +++
NEWS | 3 +-
math/libm-test.inc | 170 ++++++++++++++++++++++++++++++++---
sysdeps/ieee754/ldbl-96/s_lroundl.c | 8 +-
4 files changed, 178 insertions(+), 15 deletions(-)
--
You are receiving this mail because:
You are on the CC list for the bug.