[Bug math/20919] Bad pow (qNaN, 0) result with -lieee

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

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

--- 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  72d839a42f4c4ed2e0a5202a0d9829c3debae20f (commit)
      from  84aa75162cd5ba73caa76864496fadd2551a5caa (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=72d839a42f4c4ed2e0a5202a0d9829c3debae20f

commit 72d839a42f4c4ed2e0a5202a0d9829c3debae20f
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Fri Dec 2 22:50:46 2016 +0000

    Fix pow (qNaN, 0) result with -lieee (bug 20919), remove dead parts of
wrappers.

    The dbl-64 implementation of __ieee754_pow returns a NaN for pow
    (qNaN, 0) when it should return 1.  Normally this is covered up by the
    wrappers ending up calling __kernel_standard which fixes up the result
    for this case, but for -lieee the wrappers are bypassed and the bad
    result gets through as a return value.

    Now, the wrappers fixing this are dealing with variant error handling
    that wants a result of NaN for pow (qNaN, 0), and only ever call
    __kernel_standard for this case if NaN resulted from __ieee754_pow.
    This leads to a question of whether the dbl-64 code might be
    deliberately returning NaN in order to use those code paths.  However,
    I can find no sign that this is deliberate.  If it were deliberate one
    would expect other implementations to do the same, and would expect
    the return of NaN to be very old, but it appears it came in by
    accident when the present e_pow.c implementation replaced an fdlibm
    implementation in 2001.  So it appears to be unintended that this path
    through the pow wrapper could be used at all.

    So this patch fixes the implementation to return 1 in this case as
    expected.  This is consistent with all the other implementations.  The
    relevant path through the wrappers is now unreachable, so is removed
    (which is the main motivation of this patch: to avoid that path
    becoming accidentally reachable when implementing TS 18661-1 semantics
    that pow (sNaN, 0) should return qNaN with "invalid" raised).  Another
    path that would require __ieee754_pow (0, 0) to return 0 is also
    unreachable (as all implementations return 1, in accordance with C99
    semantics), so is removed as well.

    Note: we don't have anything set up to test -lieee, which in any case
    is obsolescent (at some point we should remove the ability for new
    programs to access _LIB_VERSION or define matherr and have it called
    by glibc).  So testing will be implicit through sNaN tests added when
    making sNaN inputs work correctly for pow functions.

    Tested for x86_64 and x86.

        [BZ #20919]
        * sysdeps/ieee754/dbl-64/e_pow.c (__ieee754_pow): Do not return
        NaN first argument when raised to power 0.
        * math/w_pow.c (__pow): Do not check for NaN or zero results from
        raising to power zero.
        * math/w_powf.c (__powf): Likewise.
        * math/w_powl.c (__powl): Likewise.
        * sysdeps/ieee754/k_standard.c (__kernel_standard): Do not handle
        pow (0, 0) or pow (NaN, 0).

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

Summary of changes:
 ChangeLog                      |   12 ++++++++++++
 math/w_pow.c                   |   24 +++++-------------------
 math/w_powf.c                  |   24 +++++-------------------
 math/w_powl.c                  |   24 +++++-------------------
 sysdeps/ieee754/dbl-64/e_pow.c |    3 ++-
 sysdeps/ieee754/k_standard.c   |   30 ------------------------------
 6 files changed, 29 insertions(+), 88 deletions(-)

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