[Bug math/22225] nearbyint arithmetic moved before feholdexcept

["cvs-commit at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=22225

--- 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  f124cb381116b5809de198327690ad0bd8d1478e (commit)
      from  7edd06916d0f18714f323b180b890f1fea39e1ff (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=f124cb381116b5809de198327690ad0bd8d1478e

commit f124cb381116b5809de198327690ad0bd8d1478e
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Thu Sep 28 01:59:02 2017 +0000

    Fix nearbyint arithmetic moved before feholdexcept (bug 22225).

    In <https://sourceware.org/ml/libc-alpha/2013-05/msg00722.html> I
    remarked on the possibility of arithmetic in various nearbyint
    implementations being scheduled before feholdexcept calls, resulting
    in spurious "inexact" exceptions.

    I'm now actually observing this occurring in glibc built for ARM with
    GCC 7 (in fact, both copies of the same addition/subtraction sequence
    being combined and moved out before the conditionals and
    feholdexcept/fesetenv pairs), resulting in test failures.

    This patch makes the nearbyint implementations with this particular
    feholdexcept / arithmetic / fesetenv pattern consistently use
    math_opt_barrier on the function argument when first used in
    arithmetic, and also consistently use math_force_eval before fesetenv
    (the latter was generally already done, but the dbl-64/wordsize-64
    implementation used math_opt_barrier instead, and as
    math_opt_barrier's intended effect is through its output value being
    used, such a use that doesn't use the return value is suspect).

    Tested for x86_64 (--disable-multi-arch so more of these
    implementations get used), and for ARM in a configuration where I saw
    the problem scheduling.

        [BZ #22225]
        * sysdeps/ieee754/dbl-64/s_nearbyint.c (__nearbyint): Use
        math_opt_barrier on argument when doing arithmetic on it.
        * sysdeps/ieee754/dbl-64/wordsize-64/s_nearbyint.c (__nearbyint):
        Likewise.  Use math_force_eval not math_opt_barrier after
        arithmetic.
        * sysdeps/ieee754/flt-32/s_nearbyintf.c (__nearbyintf): Use
        math_opt_barrier on argument when doing arithmetic on it.
        * sysdeps/ieee754/ldbl-128/s_nearbyintl.c (__nearbyintl):
        Likewise.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog                                        |   13 +++++++++++++
 sysdeps/ieee754/dbl-64/s_nearbyint.c             |    4 ++--
 sysdeps/ieee754/dbl-64/wordsize-64/s_nearbyint.c |    8 ++++----
 sysdeps/ieee754/flt-32/s_nearbyintf.c            |    4 ++--
 sysdeps/ieee754/ldbl-128/s_nearbyintl.c          |    4 ++--
 5 files changed, 23 insertions(+), 10 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.