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/108685] [10/11 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 since r13-2388-ga651e6d59188da Date: Tue, 02 May 2023 20:15:53 +0000 [thread overview] Message-ID: <bug-108685-4-bAy7N4tWo6@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-108685-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108685 --- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-11 branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:38812e9e87c4d42f1d9916788c92f17273d772dc commit r11-10725-g38812e9e87c4d42f1d9916788c92f17273d772dc Author: Jakub Jelinek <jakub@redhat.com> Date: Fri Mar 17 08:46:28 2023 +0100 openmp: Fix up handling of doacross loops with noreturn body in loops [PR108685] The following patch fixes an ICE with doacross loops which have a single entry no exit body, at least one of the ordered > collapse loops isn't guaranteed to have at least one iteration and the whole doacross loop is inside some other loop. The OpenMP constructs aren't represented by struct loop until the omp expansions, so for a normal doacross loop which doesn't have a noreturn body the entry_bb with the GOMP_FOR statement and the first bb of the body typically have the same loop_father, and if the doacross loop isn't inside of some other loop and the body is noreturn as well, both are part of loop 0. The problematic case is when the entry_bb is inside of some deeper loop, but the body, because it falls through into EXIT, has loop 0 as loop_father. l0_bb is created by splitting the entry_bb fallthru edge into l1_bb, and because the two basic blocks have different loop_father, a common loop is found for those (which is loop 0). Now, if the doacross loop has collapse == ordered or all the ordered > collapse loops are guaranteed to iterate at least once, all is still fine, because all enter the l1_bb (body), which doesn't return and so doesn't loop further either. But, if one of those loops could loop 0 times, the user written body wouldn't be reached at all, so unlike the expectations the whole construct actually wouldn't be noreturn if entry_bb is encountered and decides to handle at least one iteration. In this case, we need to fix up, move the l0_bb into the same loop as entry_bb (initially) and for the extra added loops put them as children of that same loop, rather than of loop 0. 2023-03-17 Jakub Jelinek <jakub@redhat.com> PR middle-end/108685 * omp-expand.c (expand_omp_for_ordered_loops): Add L0_BB argument, use its loop_father rather than BODY_BB's loop_father. (expand_omp_for_generic): Adjust expand_omp_for_ordered_loops caller. If broken_loop with ordered > collapse and at least one of those extra loops aren't guaranteed to have at least one iteration, change l0_bb's loop_father to entry_bb's loop_father. Set cont_bb's loop_father to l0_bb's loop_father rather than l1_bb's. * c-c++-common/gomp/doacross-8.c: New test. (cherry picked from commit 713fa5db8ceb4ba8783a0d690ceb4c07f2ff03d0)
next prev parent reply other threads:[~2023-05-02 20:15 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-02-06 18:50 [Bug c/108685] New: [13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 gscfq@t-online.de 2023-02-06 20:20 ` [Bug middle-end/108685] " pinskia at gcc dot gnu.org 2023-02-07 14:06 ` rguenth at gcc dot gnu.org 2023-02-10 9:05 ` [Bug middle-end/108685] [13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 since r13-2388-ga651e6d59188da marxin at gcc dot gnu.org 2023-02-15 13:41 ` [Bug middle-end/108685] [10/11/12/13 " jakub at gcc dot gnu.org 2023-02-15 15:15 ` jakub at gcc dot gnu.org 2023-02-15 16:14 ` jakub at gcc dot gnu.org 2023-02-21 12:50 ` rguenth at gcc dot gnu.org 2023-03-16 17:32 ` jakub at gcc dot gnu.org 2023-03-17 8:00 ` cvs-commit at gcc dot gnu.org 2023-03-17 8:29 ` [Bug middle-end/108685] [10/11/12 " jakub at gcc dot gnu.org 2023-03-19 5:31 ` cvs-commit at gcc dot gnu.org 2023-03-20 10:30 ` [Bug middle-end/108685] [10/11 " jakub at gcc dot gnu.org 2023-05-02 20:15 ` cvs-commit at gcc dot gnu.org [this message] 2023-05-03 10:37 ` [Bug middle-end/108685] [10 " jakub at gcc dot gnu.org 2023-05-03 15:22 ` cvs-commit at gcc dot gnu.org 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-108685-4-bAy7N4tWo6@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).