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/99322] [11 Regression] ICE in change_scope, at final.c:1480
Date: Fri, 05 Mar 2021 20:59:33 +0000	[thread overview]
Message-ID: <bug-99322-4-en1iqYlcqQ@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-99322-4@http.gcc.gnu.org/bugzilla/>

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

--- 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:a3ad6489d38982434faef3bc5f33e3c28c5f7c74

commit r11-7533-ga3ad6489d38982434faef3bc5f33e3c28c5f7c74
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Mar 5 21:52:35 2021 +0100

    openmp: Avoid ICEs due to orphaned labels in OpenMP regions [PR99322]

    When performing cfg cleanup at the end of cfg pass, if there are any OpenMP
    regions and some basic blocks are unreachable and contain forced labels,
    remove_bb moves the labels to previous bb, but if the two bb belong to
different
    OpenMP regions, that means it will end up in a different function from
where
    it was assumed to be and checked e.g. during gimplification or OpenMP
region
    SESE checking.

    The following patch will place the labels to some bb from the right OpenMP
    region if the previous bb is not that.  I think it should happen very
rarely,
    normally the bbs from each OpenMP region should be from the before-cfg pass
    adjacent and the problems will usually be only if the OpenMP regions are
    no-return, so I hope it isn't fatal that it searches through all bbs on the
miss.
    If it turns out to be a problem, it can always lazily create some better
data
    structure and maintain it through bb removals when it reaches that case the
    first time.

    2021-03-05  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/99322
            * tree-cfg.c (bb_to_omp_idx): New variable.
            (execute_build_cfg): Release the bb_to_omp_idx vector after
            cleanup_tree_cfg returns.
            (handle_abnormal_edges): Remove bb_to_omp_idx argument, adjust
            for bb_to_omp_idx being a vec<int> instead of pointer to array
            of ints.
            (make_edges): Remove bb_to_omp_idx local variable, don't pass
            it to handle_abnormal_edges, adjust for bb_to_omp_idx being a
            vec<int> instead of pointer to array of ints and don't free/release
            it at the end.
            (remove_bb): When removing a bb and placing forced label somewhere
            else, ensure it is put into the same OpenMP region during cfg
            pass if possible or to entry successor as fallback.  Unregister
            bb from bb_to_omp_idx.

            * c-c++-common/gomp/pr99322.c: New test.

  parent reply	other threads:[~2021-03-05 20:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-01 17:02 [Bug c/99322] New: " gscfq@t-online.de
2021-03-01 19:10 ` [Bug c/99322] " pinskia at gcc dot gnu.org
2021-03-02  9:42 ` marxin at gcc dot gnu.org
2021-03-05 14:52 ` jakub at gcc dot gnu.org
2021-03-05 16:41 ` jakub at gcc dot gnu.org
2021-03-05 16:59 ` [Bug middle-end/99322] " jakub at gcc dot gnu.org
2021-03-05 20:59 ` cvs-commit at gcc dot gnu.org [this message]
2021-03-05 21:01 ` 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-99322-4-en1iqYlcqQ@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).