[Bug tree-optimization/64284] [5 Regression] ICE: Segmentation fault

rguenth at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Fri Dec 12 11:45:00 GMT 2014


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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Sth like

Index: tree-ssa-threadupdate.c
===================================================================
--- tree-ssa-threadupdate.c     (revision 218621)
+++ tree-ssa-threadupdate.c     (working copy)
@@ -2364,7 +2364,7 @@ duplicate_seme_region (edge entry, edge
                       basic_block *region_copy)
 {
   unsigned i;
-  bool free_region_copy = false, copying_header = false;
+  bool free_region_copy = false;
   struct loop *loop = entry->dest->loop_father;
   edge exit_copy;
   edge redirected;
@@ -2388,10 +2388,7 @@ duplicate_seme_region (edge entry, edge

   initialize_original_copy_tables ();

-  if (copying_header)
-    set_loop_copy (loop, loop_outer (loop));
-  else
-    set_loop_copy (loop, loop);
+  set_loop_copy (loop, loop);

   if (!region_copy)
     {
@@ -2453,6 +2450,8 @@ duplicate_seme_region (edge entry, edge
   }

   /* Redirect the entry and add the phi node arguments.  */
+  if (entry->dest == loop->header)
+    mark_loop_for_removal (loop);
   redirected = redirect_edge_and_branch (entry, get_bb_copy (entry->dest));
   gcc_assert (redirected != NULL);
   flush_pending_stmts (entry);

"works" but results in the less than optimal

fix_loop_structure: fixing up loops for function
fix_loop_structure: removing loop 1
flow_loops_find: discovered new loop 2 with header 5

in the testcase the loop header will be entry->src it seems - not sure
how reliably that is in the full generality of duplicate_seme_region.
We know that all blocks are contained in the same loop, so it must be
possible to compute where the header goes.

Ideally we'd simply set loop->header and loop->latch to the correct values,
marking loops for fixup (to recompute BB ownership - or do even that
ourselves).
The testcase has two latches later, thus loop->latch would be NULL, but
both VRP and DOM init loops without LOOPS_MAY_HAVE_MULTIPLE_LATCHES so we'd
have to disambiguate the loops.

That said - the above patch works.



More information about the Gcc-bugs mailing list