[Bug math/26073] New: getpayload() has wrong return value

[Bug math/26073] New: getpayload() has wrong return value

[tydeman.fred at gmail dot com]

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

            Bug ID: 26073
           Summary: getpayload() has wrong return value
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: math
          Assignee: unassigned at sourceware dot org
          Reporter: tydeman.fred at gmail dot com
  Target Milestone: ---

/*
 * getpayload() bug
 * C2X has in F.10.13.1: If *x is not a NaN, the return result is -1.
 */
#define __STDC_WANT_IEC_60559_BFP_EXT__
#include <math.h>
#include <stdio.h>

int main(void){
  double d = 1.0;
  d = getpayload( &d ); /* not a NaN argument */
  if(-1.0 != d) (void)printf("Bug: d=%g\n", d);
  return 0;
}

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

[Bug math/26073] getpayload() has wrong return value

[jsm28 at gcc dot gnu.org]

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

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |2.32
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #1 from Joseph Myers <jsm28 at gcc dot gnu.org> ---
Fixed for 2.32.

commit 6c010c5dde1735f93cc3a6597cdcc2b482af85f8
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Mon Jul 6 16:18:02 2020 +0000

    Use C2x return value from getpayload of non-NaN (bug 26073).

    In TS 18661-1, getpayload had an unspecified return value for a
    non-NaN argument, while C2x requires the return value -1 in that case.

    This patch implements the return value of -1.  I don't think this is
    worth having a new symbol version that's an alias of the old one,
    although occasionally we do that in such cases where the new function
    semantics are a refinement of the old ones (to avoid programs relying
    on the new semantics running on older glibc versions but not behaving
    as intended).

    Tested for x86_64 and x86; also ran math/ tests for aarch64 and
    powerpc.

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