This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug math/20947] New: fmax, fmin sNaN handling
- From: "jsm28 at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 07 Dec 2016 18:37:20 +0000
- Subject: [Bug math/20947] New: fmax, fmin sNaN handling
- Auto-submitted: auto-generated
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.