* [Bug middle-end/108685] [13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748
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 ` pinskia at gcc dot gnu.org
2023-02-07 14:06 ` rguenth at gcc dot gnu.org
` (14 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-02-06 20:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108685
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Most likely r13-2388-ga651e6d59188da
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/108685] [13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748
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
` (13 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-02-07 14:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108685
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |ice-checking
Target Milestone|--- |13.0
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/108685] [13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 since r13-2388-ga651e6d59188da
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 ` 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
` (12 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: marxin at gcc dot gnu.org @ 2023-02-10 9:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108685
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org,
| |marxin at gcc dot gnu.org
Summary|[13 Regression] ICE in |[13 Regression] ICE in
|verify_loop_structure, at |verify_loop_structure, at
|cfgloop.cc:1748 |cfgloop.cc:1748 since
| |r13-2388-ga651e6d59188da
--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #1)
> Most likely r13-2388-ga651e6d59188da
Yes.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/108685] [10/11/12/13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 since r13-2388-ga651e6d59188da
2023-02-06 18:50 [Bug c/108685] New: [13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 gscfq@t-online.de
` (2 preceding siblings ...)
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 ` jakub at gcc dot gnu.org
2023-02-15 15:15 ` jakub at gcc dot gnu.org
` (11 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-02-15 13:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108685
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Last reconfirmed| |2023-02-15
Status|UNCONFIRMED |NEW
Summary|[13 Regression] ICE in |[10/11/12/13 Regression]
|verify_loop_structure, at |ICE in
|cfgloop.cc:1748 since |verify_loop_structure, at
|r13-2388-ga651e6d59188da |cfgloop.cc:1748 since
| |r13-2388-ga651e6d59188da
Target Milestone|13.0 |10.5
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This actually ICEs all the way to r6-3899-gd9a6bd32adc40a7e1e5c7269 if you use
depend (source) instead of doacross (source:).
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/108685] [10/11/12/13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 since r13-2388-ga651e6d59188da
2023-02-06 18:50 [Bug c/108685] New: [13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 gscfq@t-online.de
` (3 preceding siblings ...)
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
` (10 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-02-15 15:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108685
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
expand_omp_for_generic like other ompexp functions has the notion of
broken_loop for
loops where the body doesn't fall through to the artificial #pragma omp
continue.
This works fine even for doacross loops if they have ordered equals collapse or
all the loops between ordered (inclusive) and collapse (exclusive) have compile
time constant non-zero number of iterations.
The problem is when they could have zero iterations (as in the testcase) or do
have those provably - say if l < a above is replaced with l < -2, in that case
while the ultimate body is a broken loop, either conditionally or always that
ultimate body will not be encountered at runtime at all, and the loop will do
nothing at all. In that case
the loop is no longer a non-loop (broken_loop) because in some cases or all it
can actually loop.
We can I think detect that after the expand_omp_for_init_counts call in
expand_omp_for_generic. The question is if we at that point can add an
artificial cont_bb somewhere, set broken_loop to false and do whatever is
needed to make the rest of the function work as if it wasn't a broken loop.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/108685] [10/11/12/13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 since r13-2388-ga651e6d59188da
2023-02-06 18:50 [Bug c/108685] New: [13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 gscfq@t-online.de
` (4 preceding siblings ...)
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
` (9 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-02-15 16:14 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108685
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Though, we have such code already:
if (broken_loop)
{
int i;
for (i = fd->collapse; i < fd->ordered; i++)
{
tree type = TREE_TYPE (fd->loops[i].v);
tree this_cond
= fold_build2 (fd->loops[i].cond_code, boolean_type_node,
fold_convert (type, fd->loops[i].n1),
fold_convert (type, fd->loops[i].n2));
if (!integer_onep (this_cond))
break;
}
if (i < fd->ordered)
{
cont_bb
= create_empty_bb (EXIT_BLOCK_PTR_FOR_FN (cfun)->prev_bb);
add_bb_to_loop (cont_bb, l1_bb->loop_father);
gimple_stmt_iterator gsi = gsi_after_labels (cont_bb);
gimple *g = gimple_build_omp_continue (fd->loop.v, fd->loop.v);
gsi_insert_before (&gsi, g, GSI_SAME_STMT);
make_edge (cont_bb, l3_bb, EDGE_FALLTHRU);
make_edge (cont_bb, l1_bb, 0);
l2_bb = create_empty_bb (cont_bb);
broken_loop = false;
}
}
and at least when the outermost for (;;) is missing, it works fine.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/108685] [10/11/12/13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 since r13-2388-ga651e6d59188da
2023-02-06 18:50 [Bug c/108685] New: [13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 gscfq@t-online.de
` (5 preceding siblings ...)
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
` (8 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-02-21 12:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108685
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P2
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/108685] [10/11/12/13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 since r13-2388-ga651e6d59188da
2023-02-06 18:50 [Bug c/108685] New: [13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 gscfq@t-online.de
` (6 preceding siblings ...)
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
` (7 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-03-16 17:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108685
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 54685
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54685&action=edit
gcc13-pr108685.patch
Untested fix.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/108685] [10/11/12/13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 since r13-2388-ga651e6d59188da
2023-02-06 18:50 [Bug c/108685] New: [13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 gscfq@t-online.de
` (7 preceding siblings ...)
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
` (6 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-03-17 8:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108685
--- Comment #7 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:713fa5db8ceb4ba8783a0d690ceb4c07f2ff03d0
commit r13-6731-g713fa5db8ceb4ba8783a0d690ceb4c07f2ff03d0
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.cc (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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/108685] [10/11/12 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 since r13-2388-ga651e6d59188da
2023-02-06 18:50 [Bug c/108685] New: [13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 gscfq@t-online.de
` (8 preceding siblings ...)
2023-03-17 8:00 ` cvs-commit at gcc dot gnu.org
@ 2023-03-17 8:29 ` jakub at gcc dot gnu.org
2023-03-19 5:31 ` cvs-commit at gcc dot gnu.org
` (5 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-03-17 8:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108685
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[10/11/12/13 Regression] |[10/11/12 Regression] ICE
|ICE in |in verify_loop_structure,
|verify_loop_structure, at |at cfgloop.cc:1748 since
|cfgloop.cc:1748 since |r13-2388-ga651e6d59188da
|r13-2388-ga651e6d59188da |
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk so far.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/108685] [10/11/12 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 since r13-2388-ga651e6d59188da
2023-02-06 18:50 [Bug c/108685] New: [13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 gscfq@t-online.de
` (9 preceding siblings ...)
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
` (4 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-03-19 5:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108685
--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:d1b61495f60141dd9c8cad4a699d5adcecc56b85
commit r12-9291-gd1b61495f60141dd9c8cad4a699d5adcecc56b85
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.cc (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)
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/108685] [10/11 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 since r13-2388-ga651e6d59188da
2023-02-06 18:50 [Bug c/108685] New: [13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 gscfq@t-online.de
` (10 preceding siblings ...)
2023-03-19 5:31 ` cvs-commit at gcc dot gnu.org
@ 2023-03-20 10:30 ` jakub at gcc dot gnu.org
2023-05-02 20:15 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-03-20 10:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108685
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[10/11/12 Regression] ICE |[10/11 Regression] ICE in
|in verify_loop_structure, |verify_loop_structure, at
|at cfgloop.cc:1748 since |cfgloop.cc:1748 since
|r13-2388-ga651e6d59188da |r13-2388-ga651e6d59188da
--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 12.3 too.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/108685] [10/11 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 since r13-2388-ga651e6d59188da
2023-02-06 18:50 [Bug c/108685] New: [13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 gscfq@t-online.de
` (11 preceding siblings ...)
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
2023-05-03 10:37 ` [Bug middle-end/108685] [10 " jakub at gcc dot gnu.org
` (2 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-05-02 20:15 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/108685] [10 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 since r13-2388-ga651e6d59188da
2023-02-06 18:50 [Bug c/108685] New: [13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 gscfq@t-online.de
` (12 preceding siblings ...)
2023-05-02 20:15 ` cvs-commit at gcc dot gnu.org
@ 2023-05-03 10:37 ` 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
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-05-03 10:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108685
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[10/11 Regression] ICE in |[10 Regression] ICE in
|verify_loop_structure, at |verify_loop_structure, at
|cfgloop.cc:1748 since |cfgloop.cc:1748 since
|r13-2388-ga651e6d59188da |r13-2388-ga651e6d59188da
--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 11.4 as well.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/108685] [10 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 since r13-2388-ga651e6d59188da
2023-02-06 18:50 [Bug c/108685] New: [13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 gscfq@t-online.de
` (13 preceding siblings ...)
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
15 siblings, 0 replies; 17+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-05-03 15:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108685
--- Comment #13 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:605449d80639a9892c645ce3449f01cb955512fa
commit r10-11378-g605449d80639a9892c645ce3449f01cb955512fa
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)
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/108685] [10 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 since r13-2388-ga651e6d59188da
2023-02-06 18:50 [Bug c/108685] New: [13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 gscfq@t-online.de
` (14 preceding siblings ...)
2023-05-03 15:22 ` cvs-commit at gcc dot gnu.org
@ 2023-05-04 7:24 ` jakub at gcc dot gnu.org
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-05-04 7:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108685
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 10.5 too.
^ permalink raw reply [flat|nested] 17+ messages in thread