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.
