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.
next prev 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: linkBe 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).