public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/114877] New: wrong-code for frexp(NAN, &uninitialized)
@ 2024-04-28 10:29 leni536 at gmail dot com
2024-04-28 17:46 ` [Bug middle-end/114877] [11/12/13/14/15 Regression] " pinskia at gcc dot gnu.org
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: leni536 at gmail dot com @ 2024-04-28 10:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114877
Bug ID: 114877
Summary: wrong-code for frexp(NAN, &uninitialized)
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: leni536 at gmail dot com
Target Milestone: ---
arch: x86_64
command line arguments: -std=c17 -O2 -pedantic-errors
#include <math.h>
#include <stdbool.h>
int frexp_test(bool b) {
if (b) {
int x;
(void)frexp(NAN, &x);
int y = x;
return y - x;
}
return 42;
}
https://godbolt.org/z/a1cn4cPqr
Observed behavior:
gcc optimizes the above function to always return 42 regardless of the value of
`b`. `frexp_test(true)` has defined behavior and must return 0.
Expected behavior:
The C standard seems to be unambiguous that an unspecified value is written to
`x` when `frexp` is called. Therefore `frexp_test(true)` has defined behavior
and must return 0.
GCC's semantics of `frexp(NAN, &x)` seems to be that it doesn't write to `x` at
all. This is a valid optimization of `x` is not uninitialized, this would be
equivalent to `*x = *x`, so the unspecified value produce by `frexp` can be the
same value that was already there. However this isn't valid when `x` was not
initialized in the first place and subsequent optimizations treat `x` as still
uninitialized.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug middle-end/114877] [11/12/13/14/15 Regression] wrong-code for frexp(NAN, &uninitialized)
2024-04-28 10:29 [Bug c/114877] New: wrong-code for frexp(NAN, &uninitialized) leni536 at gmail dot com
@ 2024-04-28 17:46 ` pinskia at gcc dot gnu.org
2024-04-30 9:39 ` rguenth at gcc dot gnu.org
2024-04-30 9:59 ` leni536 at gmail dot com
2 siblings, 0 replies; 4+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-04-28 17:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114877
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Known to fail| |9.5.0
Known to work| |4.2.0
Target Milestone|--- |11.5
Summary|wrong-code for frexp(NAN, |[11/12/13/14/15 Regression]
|&uninitialized) |wrong-code for frexp(NAN,
| |&uninitialized)
Ever confirmed|0 |1
Last reconfirmed| |2024-04-28
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
frexp folding was introduced with r0-79285-g7a2a25ab4f30cc for GCC 4.3.0 which
had the issue
BUT we produced good code until GCC 10.1.0 which changed the behavior of ccp
here.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug middle-end/114877] [11/12/13/14/15 Regression] wrong-code for frexp(NAN, &uninitialized)
2024-04-28 10:29 [Bug c/114877] New: wrong-code for frexp(NAN, &uninitialized) leni536 at gmail dot com
2024-04-28 17:46 ` [Bug middle-end/114877] [11/12/13/14/15 Regression] " pinskia at gcc dot gnu.org
@ 2024-04-30 9:39 ` rguenth at gcc dot gnu.org
2024-04-30 9:59 ` leni536 at gmail dot com
2 siblings, 0 replies; 4+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-04-30 9:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114877
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jsm28 at gcc dot gnu.org
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
The standard says the results are unspecified, it doesn't say *p is written to,
so I'm not sure there's a bug here.
Indeed we do
case rvc_nan:
case rvc_inf:
/* For +-NaN or +-Inf, *exp is unspecified, return arg0. */
return omit_one_operand_loc (loc, rettype, arg0, arg1);
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug middle-end/114877] [11/12/13/14/15 Regression] wrong-code for frexp(NAN, &uninitialized)
2024-04-28 10:29 [Bug c/114877] New: wrong-code for frexp(NAN, &uninitialized) leni536 at gmail dot com
2024-04-28 17:46 ` [Bug middle-end/114877] [11/12/13/14/15 Regression] " pinskia at gcc dot gnu.org
2024-04-30 9:39 ` rguenth at gcc dot gnu.org
@ 2024-04-30 9:59 ` leni536 at gmail dot com
2 siblings, 0 replies; 4+ messages in thread
From: leni536 at gmail dot com @ 2024-04-30 9:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114877
--- Comment #3 from Lénárd Szolnoki <leni536 at gmail dot com> ---
(In reply to Richard Biener from comment #2)
> The standard says the results are unspecified, it doesn't say *p is written
> to,
> so I'm not sure there's a bug here.
C17 (N2176) says in the library section:
"The frexp functions break a floating-point number into a normalized fraction
and an integral power of 2. They store the integer in the int object pointed to
by exp."
"If value is not a floating-point number or if the integral power of 2 is
outside the range of int, the results are unspecified. Otherwise, the frexp
functions return the value x, such that x has a magnitude in the interval [1/2,
1) or zero, and value equals x × 2*exp . If value is zero, both parts of
the result are zero."
This might be a little bit ambiguous, but my reading is that an int value is
always stored, but sometimes the "results are unspecified", where I assume
"results" refer to the fractional part and the integer exponent. An unspecified
result then is stored to the object pointed to by exp.
However further down in Annex F (relevant for targets with IEC 60559, such as
x86_64):
"frexp(±∞, exp) returns ±∞, and stores an unspecified value in the object
pointed to by exp."
"frexp(NaN, exp) stores an unspecified value in the object pointed to by exp
(and returns a NaN)."
This is a lot less ambiguous.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-04-30 9:59 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-28 10:29 [Bug c/114877] New: wrong-code for frexp(NAN, &uninitialized) leni536 at gmail dot com
2024-04-28 17:46 ` [Bug middle-end/114877] [11/12/13/14/15 Regression] " pinskia at gcc dot gnu.org
2024-04-30 9:39 ` rguenth at gcc dot gnu.org
2024-04-30 9:59 ` leni536 at gmail dot com
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).