[Bug c++/88173] `std::numeric_limits<T>::quiet_NaN()` is not always constexpr

[Bug c++/88173] `std::numeric_limits<T>::quiet_NaN()` is not always constexpr

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2020-12-08
                 CC|                            |jason at gcc dot gnu.org

--- Comment #10 from Jason Merrill <jason at gcc dot gnu.org> ---
Shorter:

#define inf __builtin_huge_val()
#define nan __builtin_nan("")

constexpr bool b1 = inf > nan; // OK
constexpr bool b2 = nan < inf; // ‘(+QNaN <= 1.7976931348623157e+308)’ is not a
constant expression

[Bug middle-end/88173] constant folding of NaN comparison depends on order of operands

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|`std::numeric_limits<T>::qu |constant folding of NaN
                   |iet_NaN()` is not always    |comparison depends on order
                   |constexpr                   |of operands
          Component|c++                         |middle-end

--- Comment #11 from Jason Merrill <jason at gcc dot gnu.org> ---
Middle-end issue; the patterns in match.pd handle these equivalent comparisons
very differently.

[Bug middle-end/88173] constant folding of NaN comparison depends on order of operands

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
What should be the exact rules for C++ floating point evaluation that trigger
non-constant expressions?  And shall that depend (like it partly does for GCC
currently) on e.g. -ftrapping-math and other command line options?
1.0 / 0.0 - division by zero (for floating point results in Inf)
10000000000000.0 + 0.000000000000001 - inexact (hope this one not)
inf - inf - invalid - non-NaN operands resulting in NaN result
sqrt (-1) - likewise
DBL_MAX * DBL_MAX - overflow
DBL_MIN * DBL_MIN - underflow
NaN + 1.0 - one or both operands NaN resulting in NaN
sNaN + 1.0 - at least one operand sNaN

[Bug middle-end/88173] constant folding of NaN comparison depends on order of operands

[roger at nextmovesoftware dot com]

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

Roger Sayle <roger at nextmovesoftware dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |roger at nextmovesoftware dot com
                 CC|                            |roger at nextmovesoftware dot com
             Status|NEW                         |ASSIGNED

--- Comment #13 from Roger Sayle <roger at nextmovesoftware dot com> ---
Patch proposed.
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579747.html

[Bug middle-end/88173] constant folding of NaN comparison depends on order of operands

[cvs-commit at gcc dot gnu.org]

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

--- Comment #14 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Roger Sayle <sayle@gcc.gnu.org>:

https://gcc.gnu.org/g:e9e46864cd0695d2dcec5c513f249b1e1ab0056f

commit r12-3660-ge9e46864cd0695d2dcec5c513f249b1e1ab0056f
Author: Roger Sayle <roger@nextmovesoftware.com>
Date:   Sun Sep 19 09:07:01 2021 +0100

    PR middle-end/88173: More constant folding of NaN comparisons.

    This patch tackles PR middle-end/88173 where the order of operands in
    a comparison affects constant folding.  As diagnosed by Jason Merrill,
    "match.pd handles these comparisons very differently".  The history is
    that the middle end, typically canonicalizes comparisons to place
    constants on the right, but when a comparison contains two constants
    we need to check/transform both constants, i.e. on both the left and the
    right.  Hence the added lines below duplicate for @0 the same transform
    applied a few lines above for @1.

    Whilst preparing the testcase, I noticed that this transformation is
    incorrectly disabled with -fsignaling-nans even when both operands are
    known not be be signaling NaNs, so I've corrected that and added a
    second test case.  Unfortunately, c-c++-common/pr57371-4.c then starts
    failing, as it doesn't distinguish QNaNs (which are quiet) from SNaNs
    (which signal), so this patch includes a minor tweak to the expected
    behaviour for QNaNs in that existing test.

    2021-09-19  Roger Sayle <roger@nextmovesoftware.com>

    gcc/ChangeLog
            PR middle-end/88173
            * match.pd (cmp @0 REAL_CST@1): When @0 is also REAL_CST, apply
            the same transformations as to @1.  For comparisons against NaN,
            don't check HONOR_SNANS but confirm that neither operand is a
            signaling NaN.

    gcc/testsuite/ChangeLog
            PR middle-end/88173
            * c-c++-common/pr57371-4.c: Tweak/correct test case for QNaNs.
            * g++.dg/pr88173-1.C: New test case.
            * g++.dg/pr88173-2.C: New test case.

[Bug middle-end/88173] constant folding of NaN comparison depends on order of operands

[roger at nextmovesoftware dot com]

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

Roger Sayle <roger at nextmovesoftware dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.0
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #15 from Roger Sayle <roger at nextmovesoftware dot com> ---
This has been fixed on mainline.

[Bug middle-end/88173] constant folding of NaN comparison depends on order of operands

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjansche at google dot com

--- Comment #16 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 88683 has been marked as a duplicate of this bug. ***

[Bug middle-end/88173] constant folding of NaN comparison depends on order of operands

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jonas.rahlf.basf at gmail dot com

--- Comment #17 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 101795 has been marked as a duplicate of this bug. ***