[Bug math/20947] fmax, fmin sNaN handling

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

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

--- Comment #3 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  0a2546cdaa4284cc6ed6af06835fd858ba341838 (commit)
      from  67f779f1ead0bf38d1ca0e882e20c7ce0c03c204 (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=0a2546cdaa4284cc6ed6af06835fd858ba341838

commit 0a2546cdaa4284cc6ed6af06835fd858ba341838
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Thu Dec 15 23:52:18 2016 +0000

    Fix x86, x86_64 fmax, fmin sNaN handling, add tests (bug 20947).

    Various fmax and fmin function implementations mishandle sNaN
    arguments:

    (a) When both arguments are NaNs, the return value should be a qNaN,
    but sometimes it is an sNaN if at least one argument is an sNaN.

    (b) Under TS 18661-1 semantics, if either argument is an sNaN then the
    result should be a qNaN (whereas if one argument is a qNaN and the
    other is not a NaN, the result should be the non-NaN argument).
    Various implementations treat sNaNs like qNaNs here.

    This patch fixes the x86 and x86_64 versions (ignoring float and
    double for 32-bit x86 given the inability to reliably avoid the sNaN
    turning into a qNaN before it gets to the called function).  Tests of
    sNaN inputs to these functions are added.

    Note on architecture versions I haven't changed for this issue:
    AArch64 already gets this right (it uses a hardware instruction with
    the correct semantics for both quiet and signaling NaNs) and does not
    need changes.  It's possible Alpha, IA64, SPARC might need changes
    (this would be shown by the testsuite if so).

    Tested for x86_64 and x86 (both i686 and i586 builds, to cover the
    different x86 implementations).

        [BZ #20947]
        * sysdeps/i386/fpu/s_fmaxl.S (__fmaxl): Add the arguments when
        either is a signaling NaN.
        * sysdeps/i386/fpu/s_fminl.S (__fminl): Likewise.  Make code
        follow fmaxl more closely.
        * sysdeps/i386/i686/fpu/s_fmaxl.S (__fmaxl): Add the arguments
        when either is a signaling NaN.
        * sysdeps/i386/i686/fpu/s_fminl.S (__fminl): Likewise.
        * sysdeps/x86_64/fpu/s_fmax.S (__fmax): Likewise.
        * sysdeps/x86_64/fpu/s_fmaxf.S (__fmaxf): Likewise.
        * sysdeps/x86_64/fpu/s_fmaxl.S (__fmaxl): Likewise.
        * sysdeps/x86_64/fpu/s_fmin.S (__fmin): Likewise.
        * sysdeps/x86_64/fpu/s_fminf.S (__fminf): Likewise.
        * sysdeps/x86_64/fpu/s_fminl.S (__fminl): Likewise.
        * math/libm-test.inc (fmax_test_data): Add tests of sNaN inputs.
        (fmin_test_data): Likewise.

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

Summary of changes:
 ChangeLog                       |   19 ++++++++++
 math/libm-test.inc              |   72 +++++++++++++++++++++++++++++++++++++++
 sysdeps/i386/fpu/s_fmaxl.S      |   30 +++++++++++++++-
 sysdeps/i386/fpu/s_fminl.S      |   40 ++++++++++++++++++---
 sysdeps/i386/i686/fpu/s_fmaxl.S |   29 +++++++++++++---
 sysdeps/i386/i686/fpu/s_fminl.S |   27 +++++++++++++--
 sysdeps/x86_64/fpu/s_fmax.S     |   19 ++++++++++-
 sysdeps/x86_64/fpu/s_fmaxf.S    |   19 ++++++++++-
 sysdeps/x86_64/fpu/s_fmaxl.S    |   29 +++++++++++++---
 sysdeps/x86_64/fpu/s_fmin.S     |   19 ++++++++++-
 sysdeps/x86_64/fpu/s_fminf.S    |   19 ++++++++++-
 sysdeps/x86_64/fpu/s_fminl.S    |   27 +++++++++++++--
 12 files changed, 322 insertions(+), 27 deletions(-)

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