public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug math/26045] New: fmaxf(inf, nan) does not always work
@ 2020-05-26 12:43 florian at schanda dot org.uk
2020-05-27 9:59 ` [Bug math/26045] " amonakov at gmail dot com
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: florian at schanda dot org.uk @ 2020-05-26 12:43 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug math/26045] fmaxf(inf, nan) does not always work
2020-05-26 12:43 [Bug math/26045] New: fmaxf(inf, nan) does not always work florian at schanda dot org.uk
@ 2020-05-27 9:59 ` amonakov at gmail dot com
2020-06-01 22:52 ` joseph at codesourcery dot com
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: amonakov at gmail dot com @ 2020-05-27 9:59 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug math/26045] fmaxf(inf, nan) does not always work
2020-05-26 12:43 [Bug math/26045] New: fmaxf(inf, nan) does not always work florian at schanda dot org.uk
2020-05-27 9:59 ` [Bug math/26045] " amonakov at gmail dot com
@ 2020-06-01 22:52 ` joseph at codesourcery dot com
2020-06-02 6:18 ` amonakov at gmail dot com
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: joseph at codesourcery dot com @ 2020-06-01 22:52 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug math/26045] fmaxf(inf, nan) does not always work
2020-05-26 12:43 [Bug math/26045] New: fmaxf(inf, nan) does not always work florian at schanda dot org.uk
2020-05-27 9:59 ` [Bug math/26045] " amonakov at gmail dot com
2020-06-01 22:52 ` joseph at codesourcery dot com
@ 2020-06-02 6:18 ` amonakov at gmail dot com
2020-06-02 13:59 ` joseph at codesourcery dot com
2021-09-29 16:19 ` jsm28 at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: amonakov at gmail dot com @ 2020-06-02 6:18 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug math/26045] fmaxf(inf, nan) does not always work
2020-05-26 12:43 [Bug math/26045] New: fmaxf(inf, nan) does not always work florian at schanda dot org.uk
` (2 preceding siblings ...)
2020-06-02 6:18 ` amonakov at gmail dot com
@ 2020-06-02 13:59 ` joseph at codesourcery dot com
2021-09-29 16:19 ` jsm28 at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: joseph at codesourcery dot com @ 2020-06-02 13:59 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug math/26045] fmaxf(inf, nan) does not always work
2020-05-26 12:43 [Bug math/26045] New: fmaxf(inf, nan) does not always work florian at schanda dot org.uk
` (3 preceding siblings ...)
2020-06-02 13:59 ` joseph at codesourcery dot com
@ 2021-09-29 16:19 ` jsm28 at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: jsm28 at gcc dot gnu.org @ 2021-09-29 16:19 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-09-29 16:19 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-26 12:43 [Bug math/26045] New: fmaxf(inf, nan) does not always work florian at schanda dot org.uk
2020-05-27 9:59 ` [Bug math/26045] " amonakov at gmail dot com
2020-06-01 22:52 ` joseph at codesourcery dot com
2020-06-02 6:18 ` amonakov at gmail dot com
2020-06-02 13:59 ` joseph at codesourcery dot com
2021-09-29 16:19 ` jsm28 at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).