public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug math/28358] New: f64xdivf128 and f64xmulf128 spurious underflows
@ 2021-09-20 22:34 jsm28 at gcc dot gnu.org
2021-09-21 21:55 ` [Bug math/28358] " cvs-commit at gcc dot gnu.org
2021-09-21 21:57 ` jsm28 at gcc dot gnu.org
0 siblings, 2 replies; 3+ messages in thread
From: jsm28 at gcc dot gnu.org @ 2021-09-20 22:34 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=28358
Bug ID: 28358
Summary: f64xdivf128 and f64xmulf128 spurious underflows
Product: glibc
Version: 2.34
Status: NEW
Severity: normal
Priority: P2
Component: math
Assignee: unassigned at sourceware dot org
Reporter: jsm28 at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-* i?86-* ia64-*
The round-to-odd computations used in the libm functions that round their
results to a narrower format can yield spurious underflow exceptions in the
following circumstances: the narrowing only narrows the precision of the type
and not the exponent range (i.e., it's narrowing _Float128 to _Float64x on
x86_64, x86 or ia64), the architecture does after-rounding tininess detection
(which applies to all those architectures), the result is inexact, tiny before
rounding but not tiny after rounding (with the chosen rounding mode) for
_Float64x (which is possible for narrowing mul, div and fma, not for narrowing
add, sub or sqrt), so the underflow exception resulting from the toward-zero
computation in _Float128 is spurious for _Float64x. For example, this applies
to the following test inputs if added to auto-libm-test-in:
div 0x1p-16382 0x1.00000000000000001p0
mul 0x0.ffffffffffffffff8p-16382 0x1.00000000000000001p0
I'm working on a fix for this issue, which showed up while working on
implementing the narrowing fma functions.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug math/28358] f64xdivf128 and f64xmulf128 spurious underflows
2021-09-20 22:34 [Bug math/28358] New: f64xdivf128 and f64xmulf128 spurious underflows jsm28 at gcc dot gnu.org
@ 2021-09-21 21:55 ` cvs-commit at gcc dot gnu.org
2021-09-21 21:57 ` jsm28 at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-09-21 21:55 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=28358
--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Joseph Myers <jsm28@sourceware.org>:
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=1356f38df5be0776823eb2c40cc4e607b86b9680
commit 1356f38df5be0776823eb2c40cc4e607b86b9680
Author: Joseph Myers <joseph@codesourcery.com>
Date: Tue Sep 21 21:54:37 2021 +0000
Fix f64xdivf128, f64xmulf128 spurious underflows (bug 28358)
As described in bug 28358, the round-to-odd computations used in the
libm functions that round their results to a narrower format can yield
spurious underflow exceptions in the following circumstances: the
narrowing only narrows the precision of the type and not the exponent
range (i.e., it's narrowing _Float128 to _Float64x on x86_64, x86 or
ia64), the architecture does after-rounding tininess detection (which
applies to all those architectures), the result is inexact, tiny
before rounding but not tiny after rounding (with the chosen rounding
mode) for _Float64x (which is possible for narrowing mul, div and fma,
not for narrowing add, sub or sqrt), so the underflow exception
resulting from the toward-zero computation in _Float128 is spurious
for _Float64x.
Fixed by making ROUND_TO_ODD call feclearexcept (FE_UNDERFLOW) in the
problem cases (as indicated by an extra argument to the macro); there
is never any need to preserve underflow exceptions from this part of
the computation, because the conversion of the round-to-odd value to
the narrower type will underflow in exactly the cases in which the
function should raise that exception, but it may be more efficient to
avoid the extra manipulation of the floating-point environment when
not needed.
Tested for x86_64 and x86, and with build-many-glibcs.py.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug math/28358] f64xdivf128 and f64xmulf128 spurious underflows
2021-09-20 22:34 [Bug math/28358] New: f64xdivf128 and f64xmulf128 spurious underflows jsm28 at gcc dot gnu.org
2021-09-21 21:55 ` [Bug math/28358] " cvs-commit at gcc dot gnu.org
@ 2021-09-21 21:57 ` jsm28 at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: jsm28 at gcc dot gnu.org @ 2021-09-21 21:57 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=28358
Joseph Myers <jsm28 at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|NEW |RESOLVED
Target Milestone|--- |2.35
--- Comment #2 from Joseph Myers <jsm28 at gcc dot gnu.org> ---
Fixed for 2.35.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-09-21 21:57 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-20 22:34 [Bug math/28358] New: f64xdivf128 and f64xmulf128 spurious underflows jsm28 at gcc dot gnu.org
2021-09-21 21:55 ` [Bug math/28358] " cvs-commit at gcc dot gnu.org
2021-09-21 21:57 ` jsm28 at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).