[Bug math/26045] New: fmaxf(inf, nan) does not always work

[Bug math/26045] New: fmaxf(inf, nan) does not always work

[florian at schanda dot org.uk]

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

            Bug ID: 26045
           Summary: fmaxf(inf, nan) does not always work
           Product: glibc
           Version: 2.28
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: math
          Assignee: unassigned at sourceware dot org
          Reporter: florian at schanda dot org.uk
  Target Milestone: ---

Created attachment 12570
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12570&action=edit
example showing fmaxf does not always work

Hi

The gcc people sent me here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95329

I believe the fmaxf function does not always work correctly (I am on Debian
stable, amd64). The following piece of code produces the wrong output when
compile with no optimisation (and hence fmaxf from libm is called):

$ gcc bug.c -lm
$ ./a.out

max(-inf, nan) = nan
max(-inf, nan) = -inf

The code in question uses a special hand-crafted NaN:

#include <stdio.h>
#include <stdint.h>
#include <math.h>
#include <string.h>

int main()
{
  uint32_t bv = 0x7FACBA7E;
  // (0 11111111 01011001011101001111110)

  float a, b;
  a = -INFINITY;
  memcpy(&b, &bv, 4);

  printf("max(%f, %f) = %f\n", a, b, fmaxf(a, b));

  b = NAN;
  printf("max(%f, %f) = %f\n", a, b, fmaxf(a, b));
}

Thanks in advance, and good luck! :)

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

[Bug math/26045] fmaxf(inf, nan) does not always work

[amonakov at gmail dot com]

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

Alexander Monakov <amonakov at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amonakov at gmail dot com

--- Comment #1 from Alexander Monakov <amonakov at gmail dot com> ---
Most likely broken by commit 0a2546cdaa4 for bug 20947. The culprit is probably

  44 testb $0x40, -2(%rsp)

that tests a bit in the middle of the mantissa, where -3(%rsp) was probably
intended (to test the high bit of the mantissa).

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

[Bug math/26045] fmaxf(inf, nan) does not always work

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
I don't see a bug here.  That specially crafted NaN is a signaling NaN 
(the high bit of the significand is 0), meaning that fmaxf (which 
corresponds to maxNum from IEEE 754-2008, *not* to one of the newer 
operations from IEEE 754-2019) is correct to raise "invalid" and return a 
signaling NaN.  x86_64 is little-endian, so -3(%rsp) has less-significant 
bits than -2(%rsp).

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

[Bug math/26045] fmaxf(inf, nan) does not always work

[amonakov at gmail dot com]

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

--- Comment #3 from Alexander Monakov <amonakov at gmail dot com> ---
Yes, sorry about the endianness mixup; I misunderstood the nature of the issue
and went hunting for a non-existent bug.

Agreed that code behaves as intended, but it appears that Glibc manual was not
updated to mention the treatment of signalling NaNs (and neither were Linux man
pages).

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

[Bug math/26045] fmaxf(inf, nan) does not always work

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
Probably all the NaN references in the manual should be reviewed to see if 
they should say "quiet NaN".  (The ISO C convention that "NaN" means 
"quiet NaN" by default may not be the most helpful to readers.  We do 
refer to the fmax handling of signaling NaNs in the documentation of 
FE_SNANS_ALWAYS_SIGNAL.)

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

[Bug math/26045] fmaxf(inf, nan) does not always work

[jsm28 at gcc dot gnu.org]

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

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

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

--- Comment #5 from Joseph Myers <jsm28 at gcc dot gnu.org> ---
I updated the documentation of fmax and fmin to mention the signaling NaN
semantics as part of:

commit 90f0ac10a74b2d43b5a65aab4be40565e359be43
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Tue Sep 28 23:31:35 2021 +0000

    Add fmaximum, fminimum functions

So there was nothing to do for this issue all along as regards the code, and
now the documentation addresses the sNaN issue for these functions properly as
well.

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