[Bug rtl-optimization/49710] [4.7 Regression] segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49710 --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org 2012-01-05 19:25:19 UTC --- Author: hubicka Date: Thu Jan 5 19:25:14 2012 New Revision: 182919 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182919 Log: PR middle-end/49710 * cfgloopmanip.c (remove_path): Walk loop hiearchy upwards when unlooping loops. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr49710.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgloopmanip.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/49710] [4.7 Regression] segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49710 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org 2012-01-05 19:27:26 UTC --- Fixed.
[Bug rtl-optimization/49710] [4.7 Regression] segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49710
--- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org 2012-01-03
17:52:04 UTC ---
Hi,
after some discussion with Zdenek, it seems that the problem is wrong
assumption in remove_path that the only loops removed are at the top of loop
hiearchy. It is not true here, since innermost loops has two exits, one to
outer loop and one to the outer loop of outer loop. Only second exit gets
removed and thus outer loop stays but outer loop of the outer loop should be
unlooped.
I am testing the attached patch.
Honza
Index: cfgloopmanip.c
===
--- cfgloopmanip.c (revision 182853)
+++ cfgloopmanip.c (working copy)
@@ -291,6 +291,7 @@ remove_path (edge e)
sbitmap seen;
bool irred_invalidated = false;
edge_iterator ei;
+ struct loop *l;
if (!can_remove_branch_p (e))
return false;
@@ -315,9 +316,18 @@ remove_path (edge e)
normally. We may assume that e-dest is not a header of any loop,
as it now has exactly one predecessor. */
while (loop_outer (e-src-loop_father)
- dominated_by_p (CDI_DOMINATORS,
- e-src-loop_father-latch, e-dest))
+ dominated_by_p (CDI_DOMINATORS,
+ e-src-loop_father-latch, e-dest))
unloop (e-src-loop_father, irred_invalidated);
+ l = e-src-loop_father;
+ while (l loop_outer (l))
+{
+ while (loop_outer (loop_outer (l))
+ dominated_by_p (CDI_DOMINATORS,
+ loop_outer (l)-latch, e-dest))
+unloop (loop_outer (l), irred_invalidated);
+ l = loop_outer (l);
+}
/* Identify the path. */
nrem = find_path (e, rem_bbs);
[Bug rtl-optimization/49710] [4.7 Regression] segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49710 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |hubicka at gcc dot gnu.org |gnu.org | --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org 2011-12-28 18:41:12 UTC --- Looking into it now. I am by no means expert on this code ;))
[Bug rtl-optimization/49710] [4.7 Regression] segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49710
--- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org 2011-12-28
19:37:38 UTC ---
OK, loop hiearchy looks as follows:
loop_0 (header = 0, latch = 1, niter = )
{
bb_2 (preds = {bb_0 }, succs = {bb_3 })
bb_6 (preds = {bb_5 }, succs = {bb_13 })
bb_12 (preds = {bb_4 }, succs = {bb_1 })
loop_4 (header = 13, latch = 14, niter = )
{
bb_13 (preds = {bb_6 bb_14 }, succs = {bb_14 })
bb_14 (preds = {bb_13 }, succs = {bb_13 })
}
loop_1 (header = 3, latch = 9, niter = )
{
bb_3 (preds = {bb_2 bb_9 }, succs = {bb_4 })
bb_9 (preds = {bb_8 }, succs = {bb_3 })
loop_2 (header = 4, latch = 11, niter = )
{
bb_4 (preds = {bb_3 bb_11 }, succs = {bb_12 bb_5 })
bb_5 (preds = {bb_4 }, succs = {bb_6 bb_7 })
bb_7 (preds = {bb_5 }, succs = {bb_10 })
bb_11 (preds = {bb_10 }, succs = {bb_4 })
loop_3 (header = 10, latch = 15, niter = )
{
bb_8 (preds = {bb_10 }, succs = {bb_9 bb_15 })
bb_15 (preds = {bb_8 }, succs = {bb_10 })
bb_10 (preds = {bb_7 bb_15 }, succs = {bb_8 bb_11 })
}
}
}
}
We remove path from 10 to 8, that is closing the loop of loop_3.
Basic blocks removed are 8 9 and 15.
Finally we fail on BB 3 that is believed to be in loop 1, but header is null at
this point because of code in delete_basic_block:
504 /* If we remove the header or the latch of a loop, mark the loop for
405 removal by setting its header and latch to NULL. */
506 if (loop-latch == bb
507 || loop-header == bb)
508 {
509 loop-header = NULL;
510 loop-latch = NULL;
511 }
OK, so it seems that fix_bb_placements is not ready to see loops marked for
removal. I guess the catch is that loop peeling renders bb 3 unreachable.
I however do not understand how loop peeling can make this happen, perhaps
folding of the header condition is done?
Honza
[Bug rtl-optimization/49710] [4.7 Regression] segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49710 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-10 11:53:40 UTC --- Honza?
[Bug rtl-optimization/49710] [4.7 Regression] segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49710 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.6.1 Target Milestone|--- |4.7.0 Summary|segfault|[4.7 Regression] segfault
[Bug rtl-optimization/49710] [4.7 Regression] segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49710 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-12 08:54:29 UTC --- Caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=172430 but more probably this is just a dup of PR48813, which was for this testcase latent before. Honza, any chance you could look at that and PR48813? The ICE is in the exact same spot, base_loop is non-NULL, but base_loop-header is NULL, as the loop has been marked for removal in delete_basic_block called from remove_bbs/remove_path during the peeling. The same remove_path then calls fix_loop_placements which calls fix_bb_placements which ICEs. That delete_basic_block is apparently called on the loop-latch bb, which queues the loop for removal anyway, but loop-header hasn't been removed and its bb-loop_father still points to the loop that has now header and latch fields NULL.
