public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug math/28358] f64xdivf128 and f64xmulf128 spurious underflows
Date: Tue, 21 Sep 2021 21:55:33 +0000	[thread overview]
Message-ID: <bug-28358-131-KGccnX0SOT@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-28358-131@http.sourceware.org/bugzilla/>

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.

  reply	other threads:[~2021-09-21 21:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-20 22:34 [Bug math/28358] New: " jsm28 at gcc dot gnu.org
2021-09-21 21:55 ` cvs-commit at gcc dot gnu.org [this message]
2021-09-21 21:57 ` [Bug math/28358] " jsm28 at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-28358-131-KGccnX0SOT@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=glibc-bugs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).