[Bug math/20947] New: fmax, fmin sNaN handling

[jsm28 at gcc dot gnu.org]

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

            Bug ID: 20947
           Summary: fmax, fmin sNaN handling
           Product: glibc
           Version: 2.24
            Status: NEW
          Severity: normal
          Priority: P2
         Component: math
          Assignee: unassigned at sourceware dot org
          Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---

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 bug report excludes any issues for 32-bit x86 float and double, given the
issues with testing sNaNs in that case.

E.g., for double on x86_64, failures include (among many others):

Failure: Test: fmax (0, sNaN)
Result:
 is:          0.0000000000000000e+00   0x0.0000000000000p+0
 should be:  qNaN
Failure: Test: fmax (sNaN, sNaN)
Result:
 is:         sNaN
 should be:  qNaN
Failure: Test: fmin (0, sNaN)
Result:
 is:          0.0000000000000000e+00   0x0.0000000000000p+0
 should be:  qNaN
Failure: Test: fmin (sNaN, 9)
Result:
 is:          9.0000000000000000e+00   0x1.2000000000000p+3
 should be:  qNaN

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