[Bug c/114877] New: wrong-code for frexp(NAN, &uninitialized)

[Bug c/114877] New: wrong-code for frexp(NAN, &uninitialized)

[leni536 at gmail dot com]

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.

[Bug middle-end/114877] [11/12/13/14/15 Regression] wrong-code for frexp(NAN, &uninitialized)

[pinskia at gcc dot gnu.org]

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.

[Bug middle-end/114877] [11/12/13/14/15 Regression] wrong-code for frexp(NAN, &uninitialized)

[rguenth at gcc dot gnu.org]

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);

[Bug middle-end/114877] [11/12/13/14/15 Regression] wrong-code for frexp(NAN, &uninitialized)

[leni536 at gmail dot com]

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.