public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@gcc.gnu.org>
To: gcc-cvs@gcc.gnu.org
Subject: [gcc r10-9324] expand: Fix up find_bb_boundaries [PR98331]
Date: Fri, 29 Jan 2021 19:20:16 +0000 (GMT)	[thread overview]
Message-ID: <20210129192016.5DCC23896C28@sourceware.org> (raw)

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

commit r10-9324-gea0e1eaa30f42e108f6c716745347cc1dcfdc475
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Jan 29 10:30:09 2021 +0100

    expand: Fix up find_bb_boundaries [PR98331]
    
    When expansion emits some control flow insns etc. inside of a former GIMPLE
    basic block, find_bb_boundaries needs to split it into multiple basic
    blocks.
    The code needs to ignore debug insns in decisions how many splits to do or
    where in between some non-debug insns the split should be done, but it can
    decide where to put debug insns if they can be kept and otherwise throws
    them away (they can't stay outside of basic blocks).
    On the following testcase, we end up in the bb from expander with
    control flow insn
    debug insns
    barrier
    some other insn
    (the some other insn is effectively dead after __builtin_unreachable and
    we'll optimize that out later).
    Without debug insns, we'd do the split when encountering some other insn
    and split after PREV_INSN (some other insn), i.e. after barrier (and the
    splitting code then moves the barrier in between basic blocks).
    But if there are debug insns, we actually split before the first debug insn
    that appeared after the control flow insn, so after control flow insn,
    and get a basic block that starts with debug insns and then has a barrier
    in the middle that nothing moves it out of the bb.  This leads to ICEs and
    even if it wouldn't, different behavior from -g0.
    The reason for treating debug insns that way is a different case, e.g.
    control flow insn
    debug insns
    some other insn
    or even
    control flow insn
    barrier
    debug insns
    some other insn
    where splitting before the first such debug insn allows us to keep them
    while otherwise we would have to drop them on the floor, and in those
    situations we behave the same with -g0 and -g.
    
    So, the following patch fixes it by resetting debug_insn not just when
    splitting the blocks (it is set only after seeing a control flow insn and
    before splitting for it if needed), but also when seeing a barrier,
    which effectively means we always throw away debug insns after a control
    flow insn and before following barrier if any, but there is no way around
    that, control flow insn must be the last in the bb (BB_END) and BARRIER
    after it, debug insns aren't allowed outside of bb.
    We still handle the other cases fine (when there is no barrier or when
    debug insns appear only after the barrier).
    
    2021-01-29  Jakub Jelinek  <jakub@redhat.com>
    
            PR debug/98331
            * cfgbuild.c (find_bb_boundaries): Reset debug_insn when seeing
            a BARRIER.
    
            * gcc.dg/pr98331.c: New test.

Diff:
---
 gcc/cfgbuild.c                 |  1 +
 gcc/testsuite/gcc.dg/pr98331.c | 18 ++++++++++++++++++
 2 files changed, 19 insertions(+)

diff --git a/gcc/cfgbuild.c b/gcc/cfgbuild.c
index 478afa5fe91..9ea6056cad6 100644
--- a/gcc/cfgbuild.c
+++ b/gcc/cfgbuild.c
@@ -545,6 +545,7 @@ find_bb_boundaries (basic_block bb)
 	     if the barrier were preceded by a control_flow_insn_p insn.  */
 	  if (!flow_transfer_insn)
 	    flow_transfer_insn = prev_nonnote_nondebug_insn_bb (insn);
+	  debug_insn = NULL;
 	}
 
       if (control_flow_insn_p (insn))
diff --git a/gcc/testsuite/gcc.dg/pr98331.c b/gcc/testsuite/gcc.dg/pr98331.c
new file mode 100644
index 00000000000..951b7586a28
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr98331.c
@@ -0,0 +1,18 @@
+/* PR debug/98331 */
+/* { dg-do compile } */
+/* { dg-options "-g -O2 -fcompare-debug" } */
+/* { dg-additional-options "-march=x86-64" { target { i?86-*-* x86_64-*-* } } } */
+
+void bar (const char *);
+unsigned long long x;
+
+void
+foo (void)
+{
+  int a = 1;
+  bar ("foo");
+  int b = 2;
+  __atomic_fetch_add (&x, 1, 0);
+  int c = 3;
+  __builtin_unreachable ();
+}


                 reply	other threads:[~2021-01-29 19:20 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20210129192016.5DCC23896C28@sourceware.org \
    --to=jakub@gcc.gnu.org \
    --cc=gcc-cvs@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).