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/106805] [13 Regression] Undue optimisation of floating-point comparisons
Date: Mon, 05 Dec 2022 10:55:33 +0000	[thread overview]
Message-ID: <bug-106805-4-abL2Bvi6rb@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-106805-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:109148dd16e4bcd50faee19c49082de69d0ba26e

commit r13-4493-g109148dd16e4bcd50faee19c49082de69d0ba26e
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Mon Dec 5 11:54:45 2022 +0100

    match.pd: Don't fold nan < x etc. for -ftrapping-math [PR106805]

    As reported in the PR, the following pr106805.c testcase is miscompiled
    with the default -ftrapping-math, because we fold all the comparisons into
    constants and don't raise any exceptions.

    The match.pd pattern handles just simple comparisons, from those
    EQ/NE are quiet and don't raise exceptions on anything but sNaN, while
    GT/GE/LT/LE are signaling and do raise exceptions even on qNaN.

    fold_relational_const handles this IMHO correctly:
          /* Handle the cases where either operand is a NaN.  */
          if (real_isnan (c0) || real_isnan (c1))
            {
              switch (code)
                {
                case EQ_EXPR:
                case ORDERED_EXPR:
                  result = 0;
                  break;

                case NE_EXPR:
                case UNORDERED_EXPR:
                case UNLT_EXPR:
                case UNLE_EXPR:
                case UNGT_EXPR:
                case UNGE_EXPR:
                case UNEQ_EXPR:
                  result = 1;
                  break;

                case LT_EXPR:
                case LE_EXPR:
                case GT_EXPR:
                case GE_EXPR:
                case LTGT_EXPR:
                  if (flag_trapping_math)
                    return NULL_TREE;
                  result = 0;
                  break;

                default:
                  gcc_unreachable ();
                }

              return constant_boolean_node (result, type);
            }
    by folding the signaling comparisons only if -fno-trapping-math.
    The following patch does the same in match.pd.

    Unfortunately the pr106805.c testcase still fails, but no longer because of
    match.pd, but on the trunk because of the still unresolved ranger problems
    (same issue as for fold-overflow-1.c etc.) and on 12 branch (and presumably
    trunk too) somewhere during expansion the comparisons are also expanded
    into constants (which is ok for -fno-trapping-math, but not ok with that).

    Though, I think the patch is a small step in the direction, so I'd like
    to commit this patch without the gcc.dg/pr106805.c testcase for now.

    2022-12-05  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/106805
            * match.pd (cmp @0 REAL_CST@1): Don't optimize x cmp NaN
            or NaN cmp x to false/true for cmp >/>=/</<= if -ftrapping-math.

            * c-c++-common/pr57371-4.c: Revert 2021-09-19 changes.
            * c-c++-common/pr57371-5.c: New test.
            * gcc.c-torture/execute/ieee/fp-cmp-6.x: Add -fno-trapping-math.
            * gcc.c-torture/execute/ieee/fp-cmp-9.c: New test.
            * gcc.c-torture/execute/ieee/fp-cmp-9.x: New file.

  parent reply	other threads:[~2022-12-05 10:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-106805-4@http.gcc.gnu.org/bugzilla/>
2022-11-30 19:30 ` pinskia at gcc dot gnu.org
2022-12-02 12:48 ` jakub at gcc dot gnu.org
2022-12-02 12:49 ` jakub at gcc dot gnu.org
2022-12-05 10:55 ` cvs-commit at gcc dot gnu.org [this message]
2022-12-20 14:55 ` rguenth at gcc dot gnu.org
2023-01-13 11:27 ` rguenth at gcc dot gnu.org
2023-01-13 11:28 ` rguenth at gcc dot gnu.org
2023-01-13 16:56 ` vincent-gcc at vinc17 dot net
2023-02-03  9:23 ` jakub at gcc dot gnu.org
2023-02-27  9:14 ` [Bug middle-end/106805] " rguenth 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-106805-4-abL2Bvi6rb@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: link
Be 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).