[Bug c++/98829] New: Different results with -O3 and custom quiet NaN

[Bug c++/98829] New: Different results with -O3 and custom quiet NaN

[gnu at nemanjaboric dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98829

            Bug ID: 98829
           Summary: Different results with -O3 and custom quiet NaN
           Product: gcc
           Version: 10.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gnu at nemanjaboric dot com
  Target Milestone: ---

Created attachment 50047
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50047&action=edit
Example of the code giving different results

Hi, see the attached code which generates the different code with -O3 (compiled
with various GCC version). Two workarounds are commented in the code: to use
`std::isnan` and to copy the source object.

I couldn't find anything undefined that I'm doing here but I might be wrong.

-ffast-math _is not_ used. Just -O3 yields different result:
https://www.godbolt.org/z/nxPd8W

[Bug middle-end/98829] Different results with -O3 and custom quiet NaN

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98829

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
NaNs do prograte but as far as I know can change values as long as it is still
a NaN.

[Bug middle-end/98829] Different results with -O3 and custom quiet NaN

[gnu at nemanjaboric dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98829

--- Comment #2 from Nemanja Boric <gnu at nemanjaboric dot com> ---
Indeed, but there's a barrier in the code (is_empty) which doesn't let NaN
values to enter the computation, so they shouldn't propagate.

[Bug middle-end/98829] Different results with -O3 and custom quiet NaN

[gnu at nemanjaboric dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98829

--- Comment #3 from Nemanja Boric <gnu at nemanjaboric dot com> ---
Changing:

    static constexpr std::uint64_t kMagicNumber = 1730;
    static constexpr std::uint64_t kCustomNaN = 0x7ff0000000000000 |
kMagicNumber;

to

    static inline std::uint64_t kMagicNumber = 1730;
    static inline std::uint64_t kCustomNaN = 0x7ff0000000000000 | kMagicNumber;

also avoids the issue.

[Bug middle-end/98829] Different results with -O3 and custom quiet NaN

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98829

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
The issue is likely GCC canonicalizing the NaN somewhere and your is_value
doing a 1:1 bit comparison.  In particular we optimize MyNAN::value to

MyNAN::value ()
{
  <bb 2> [local count: 1073741824]:
  return  Nan;

but ::is_value is

MyNAN::is_value (double d)
{
  long unsigned int _2;
  bool _3;

  <bb 2> [local count: 1073741824]:
  _2 = VIEW_CONVERT_EXPR<long unsigned int>(d_1(D));
  _3 = _2 == 9218868437227407042;
  return _3;

MyNAN::value is optimized by CSE via native_encode/interpret.

I'm not sure why -O2 vs. -O3 makes a difference in the end but I think
your program is ill-formed.

[Bug middle-end/98829] Different results with -O3 and custom quiet NaN

[gnu at nemanjaboric dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98829

--- Comment #5 from Nemanja Boric <gnu at nemanjaboric dot com> ---
Yes, it seems that if the constants are `constexpr` or `static inline const`
the custom payload is gone. 

I guess this is aligned to
https://en.cppreference.com/w/cpp/types/numeric_limits/quiet_NaN

"A NaN never compares equal to itself. Copying a NaN may not preserve its bit
representation."

[Bug middle-end/98829] Different results with -O3 and custom quiet NaN

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98829

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Your custom quiet NaN is not a quiet NaN, but signaling NaN.
And, as documented, -fno-signaling-nans is the default.
If you change your custom signaling NaN into a quiet NaN,
static constexpr std::uint64_t kCustomNaN = 0x7ff8000000000000 | kMagicNumber;
or if you compile with -fsignaling-nans, this works fine, so I'd say this is
just a user error.

[Bug middle-end/98829] Different results with -O3 and custom quiet NaN

[nemanjab at amazon dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98829

Nemanja Boric <nemanjab at amazon dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nemanjab at amazon dot com

--- Comment #7 from Nemanja Boric <nemanjab at amazon dot com> ---
Sorry for the late reply. Yes, you're right, this is an user error.