public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/111009] [12/13/14 regression] -fno-strict-overflow erroneously elides null pointer checks and causes SIGSEGV on perf from linux-6.4.10
Date: Mon, 14 Aug 2023 11:34:55 +0000	[thread overview]
Message-ID: <bug-111009-4-V7QjEIHJMI@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-111009-4@http.gcc.gnu.org/bugzilla/>

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
                 CC|                            |amacleod at redhat dot com,
                   |                            |rguenth at gcc dot gnu.org
           Priority|P3                          |P2
   Target Milestone|---                         |12.4
   Last reconfirmed|                            |2023-08-14
     Ever confirmed|0                           |1

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
There's nothing really wrong with lifting the &dso->maj computation, on GIMPLE
&dso->maj is just address arithmetic.

Interestingly we unswitch the loop but only with -fwrapv-pointer.

OK, so the bug looks like we have


 if (&dso->maj != 0)
   for (;;)
     {
       if (!dso) return 1;
       if (dso == curr) return 1;
...
     }

and the if (!dso) test is optimized away since &dso->maj != 0.

That's done by DOM3 here:

Optimizing statement _21 = dso_8(D) == _11;
LKUP STMT _21 = dso_8(D) eq_expr _11
2>>> STMT _21 = dso_8(D) eq_expr _11
Optimizing statement _22 = _21 | _13;
  Replaced '_13' with constant '0'
Applying pattern match.pd:201, gimple-match-10.cc:6318
gimple_simplified to _22 = _21;
  Folded to: _22 = _21;

I don't see where _13 = 0 is entered, this is possibly ranger related:

_13 : CACHE: BB 9 DOM query for _13, found [irange] _Bool VARYING at BB3
797     GORI  recomputation attempt on edge 3->16 for _13 = dso_8(D) == 0B;
798     GORI    outgoing_edge for dso_8(D) on edge 3->16
799     GORI      compute op 1 (a_9) at if (a_9 == 0B)
        GORI        LHS =[irange] _Bool [1, 1]
        GORI        Computes a_9 = [irange] int * [0, 0] intersect Known range
: [irange] int * VARYING
        GORI      TRUE : (799) produces  (a_9) [irange] int * [0, 0]
800     GORI      compute op 1 (dso_8(D)) at a_9 = &dso_8(D)->maj;
        GORI        LHS =[irange] int * [0, 0]
        GORI        Computes dso_8(D) = [irange] struct dso * [0, 0] intersect
Known range : [irange] struct dso * VARYING
        GORI      TRUE : (800) produces  (dso_8(D)) [irange] struct dso * [0,
0]
        GORI    TRUE : (798) outgoing_edge (dso_8(D)) [irange] struct dso * [0,
0]
        GORI  TRUE : (797) recomputation (_13) [irange] _Bool [1, 1]

I don't think we can do this.  Andrew?

  parent reply	other threads:[~2023-08-14 11:34 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-14  8:26 [Bug middle-end/111009] New: " slyfox at gcc dot gnu.org
2023-08-14  9:34 ` [Bug middle-end/111009] " amonakov at gcc dot gnu.org
2023-08-14 11:34 ` rguenth at gcc dot gnu.org [this message]
2023-08-14 11:48 ` rguenth at gcc dot gnu.org
2023-08-15 17:57 ` amacleod at redhat dot com
2023-08-16 20:14 ` slyfox at gcc dot gnu.org
2023-08-16 20:21 ` sjames at gcc dot gnu.org
2023-08-16 20:40 ` slyfox at gcc dot gnu.org
2023-08-16 21:05 ` amacleod at redhat dot com
2023-08-16 21:24 ` slyfox at gcc dot gnu.org
2023-08-17 15:37 ` amacleod at redhat dot com
2023-08-17 17:39 ` cvs-commit at gcc dot gnu.org
2023-08-17 19:44 ` slyfox at gcc dot gnu.org
2024-05-08 12:03 ` [Bug middle-end/111009] [12/13 " rguenth at gcc dot gnu.org
2024-05-08 18:26 ` amacleod at redhat dot com
2024-05-09 14:32 ` cvs-commit at gcc dot gnu.org
2024-05-10  6:36 ` [Bug middle-end/111009] [12 " rguenth at gcc dot gnu.org
2024-05-13 17:49 ` cvs-commit at gcc dot gnu.org
2024-06-12 11:38 ` 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-111009-4-V7QjEIHJMI@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).