public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/88173] constant folding of NaN comparison depends on order of operands Date: Sun, 19 Sep 2021 08:08:36 +0000 [thread overview] Message-ID: <bug-88173-4-F374kzr9VW@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-88173-4@http.gcc.gnu.org/bugzilla/> 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.
next prev parent reply other threads:[~2021-09-19 8:08 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-88173-4@http.gcc.gnu.org/bugzilla/> 2020-12-08 18:52 ` [Bug c++/88173] `std::numeric_limits<T>::quiet_NaN()` is not always constexpr jason at gcc dot gnu.org 2020-12-08 19:47 ` [Bug middle-end/88173] constant folding of NaN comparison depends on order of operands jason at gcc dot gnu.org 2020-12-08 20:48 ` jakub at gcc dot gnu.org 2021-09-18 8:58 ` roger at nextmovesoftware dot com 2021-09-19 8:08 ` cvs-commit at gcc dot gnu.org [this message] 2021-09-19 21:42 ` roger at nextmovesoftware dot com 2021-11-08 10:01 ` pinskia at gcc dot gnu.org 2022-12-28 19:14 ` pinskia at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-88173-4-F374kzr9VW@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).