[Bug middle-end/88173] constant folding of NaN comparison depends on order of operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88173 Andrew Pinski changed: What|Removed |Added CC||jonas.rahlf.basf at gmail dot com --- Comment #17 from Andrew Pinski --- *** Bug 101795 has been marked as a duplicate of this bug. ***
[Bug middle-end/88173] constant folding of NaN comparison depends on order of operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88173 Andrew Pinski changed: What|Removed |Added CC||mjansche at google dot com --- Comment #16 from Andrew Pinski --- *** 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88173 Roger Sayle changed: What|Removed |Added Target Milestone|--- |12.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #15 from Roger Sayle --- This has been fixed on mainline.
[Bug middle-end/88173] constant folding of NaN comparison depends on order of operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88173 --- Comment #14 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:e9e46864cd0695d2dcec5c513f249b1e1ab0056f commit r12-3660-ge9e46864cd0695d2dcec5c513f249b1e1ab0056f Author: Roger Sayle 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 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88173 Roger Sayle 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 --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88173 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek --- 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) 10.0 + 0.001 - 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88173 Jason Merrill changed: What|Removed |Added Summary|`std::numeric_limits::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 --- Middle-end issue; the patterns in match.pd handle these equivalent comparisons very differently.
