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 rtl-optimization/108596] [10 Regression] error: EDGE_CROSSING missing across section boundary
Date: Wed, 03 May 2023 15:20:58 +0000	[thread overview]
Message-ID: <bug-108596-4-XL5x5DIkve@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-108596-4@http.gcc.gnu.org/bugzilla/>

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

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

https://gcc.gnu.org/g:73abd84646142b2a6177df9366917fea696d4df3

commit r10-11359-g73abd84646142b2a6177df9366917fea696d4df3
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Jan 31 09:46:35 2023 +0100

    bbpart: Fix up ICE on asm goto [PR108596]

    On the following testcase we have asm goto in hot block with 2 successors,
    one cold to which it both falls through and has one of the label
    pointing to it and another hot successor with another label.

    Now, during bbpart we want to ensure that no blocks from one partition fall
    through into a block in a different partition.  fix_up_fall_thru_edges
    does that by temporarily clearing the EDGE_CROSSING on the fallthrough
edge,
    calling force_nonfallthru and then depending on whether it created a new
    bb either set EDGE_CROSSING on the single successor edge from the new bb
    (the new bb is kept in the same partition as the predecessor block), or
    if no new bb has been created setting EDGE_CROSSING back on the fallthru
    edge which has been forced non-EDGE_FALLTHRU.
    For asm goto this doesn't always work, force_nonfallthru can create a new
bb
    and change the fallthrough edge to point to that, but if the original
    fallthru destination block has its label referenced among the asm goto
    labels, it will create a new non-fallthru edge for the label(s).
    But because we've temporarily cheated and cleared EDGE_CROSSING on the
edge,
    it is cleared on the new edge as well, then the caller sees we've created
    a new bb and just sets EDGE_CROSSING on the single fallthru edge from the
    new bb.  But the direct edge from cur_bb to fallthru edge's destination
    isn't handled and fails afterwards consistency checks, because it crosses
    partitions.

    The following patch notes the case and sets EDGE_CROSSING on that edge too.

    2023-01-31  Jakub Jelinek  <jakub@redhat.com>

            PR rtl-optimization/108596
            * bb-reorder.c (fix_up_fall_thru_edges): Handle the case where
cur_bb
            ends with asm goto and has a crossing fallthrough edge to the same
bb
            that contains at least one of its labels by restoring EDGE_CROSSING
            flag even on possible edge from cur_bb to new_bb successor.

            * gcc.c-torture/compile/pr108596.c: New test.

    (cherry picked from commit 603a6fbcaac1e80aa90d1d26318c881a53473066)

  parent reply	other threads:[~2023-05-03 15:20 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-30 11:31 [Bug c/108596] New: " dcb314 at hotmail dot com
2023-01-30 12:06 ` [Bug rtl-optimization/108596] " rguenth at gcc dot gnu.org
2023-01-30 12:16 ` [Bug rtl-optimization/108596] [10/11/12/13 Regression] " jakub at gcc dot gnu.org
2023-01-30 12:24 ` jakub at gcc dot gnu.org
2023-01-30 17:08 ` jakub at gcc dot gnu.org
2023-01-31  8:47 ` cvs-commit at gcc dot gnu.org
2023-01-31  8:48 ` [Bug rtl-optimization/108596] [10/11/12 " jakub at gcc dot gnu.org
2023-02-02  9:04 ` dcb314 at hotmail dot com
2023-02-10 17:46 ` cvs-commit at gcc dot gnu.org
2023-02-10 18:01 ` [Bug rtl-optimization/108596] [10/11 " jakub at gcc dot gnu.org
2023-05-02 20:14 ` cvs-commit at gcc dot gnu.org
2023-05-03 10:36 ` [Bug rtl-optimization/108596] [10 " jakub at gcc dot gnu.org
2023-05-03 15:20 ` cvs-commit at gcc dot gnu.org [this message]
2023-05-04  7:24 ` jakub 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-108596-4-XL5x5DIkve@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).