[Bug tree-optimization/47290] [4.5/4.6 Regression] memory exhausted compiling a destructor with an infinite 'for (;;);' loop

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47290

--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-18 
10:31:32 UTC ---
How about

Index: tree-eh.c
===
--- tree-eh.c   (revision 168906)
+++ tree-eh.c   (working copy)
@@ -3710,6 +3710,9 @@ cleanup_empty_eh_unsplit (basic_block bb
 if (find_edge (e-src, e_out-dest))
   return false;

+  if (!single_pred_p (e_out-dest))
+return false;
+
   /* Attempt to move the PHIs into the successor block.  */
   if (cleanup_empty_eh_merge_phis (e_out-dest, bb, e_out, false))
 {

?  The condition before was added by me for another corner-case and
of course could be removed with that patch.

[Bug tree-optimization/47290] [4.5/4.6 Regression] memory exhausted compiling a destructor with an infinite 'for (;;);' loop

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47290

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-18 
10:32:06 UTC ---
CCing Honza.  What kind of simplifications did we want to catch here?

[Bug tree-optimization/47290] [4.5/4.6 Regression] memory exhausted compiling a destructor with an infinite 'for (;;);' loop

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47290

--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-18 
13:07:06 UTC ---
Created attachment 23017
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23017
gcc46-pr47290.patch

Another possible untested patch that should handle any number of bbs in empty
infinite loop.

[Bug tree-optimization/47290] [4.5/4.6 Regression] memory exhausted compiling a destructor with an infinite 'for (;;);' loop

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47290

--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-18 
13:10:19 UTC ---
We could also limit the number of iterations:
   int i;

-  for (i = 1; VEC_iterate (eh_landing_pad, cfun-eh-lp_array, i, lp); ++i)
+  int len = VEC_length (eh_landing_pad, cfun-eh-lp_array) * 2;
+  for (i = 1; 
+   VEC_iterate (eh_landing_pad, cfun-eh-lp_array, i, lp)  i  len;
+   i++)
 if (lp)
   changed |= cleanup_empty_eh (lp);

[Bug tree-optimization/47290] [4.5/4.6 Regression] memory exhausted compiling a destructor with an infinite 'for (;;);' loop

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47290

--- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-18 
13:39:47 UTC ---
(In reply to comment #7)
 We could also limit the number of iterations:
int i;
 
 -  for (i = 1; VEC_iterate (eh_landing_pad, cfun-eh-lp_array, i, lp); ++i)
 +  int len = VEC_length (eh_landing_pad, cfun-eh-lp_array) * 2;
 +  for (i = 1; 
 +   VEC_iterate (eh_landing_pad, cfun-eh-lp_array, i, lp)  i  len;
 +   i++)
  if (lp)
changed |= cleanup_empty_eh (lp);

won't it still say changed and iterate in the caller?  Note that we could
avoid the above if we'd avoid generating new landing-pads and instead moved
the old ones.

[Bug tree-optimization/47290] [4.5/4.6 Regression] memory exhausted compiling a destructor with an infinite 'for (;;);' loop

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47290

--- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-18 
13:49:18 UTC ---
cleanup_all_empty_eh is called just once per ehcleanup pass, doesn't iterate.
If we don't want to iterate on the new pads, we could just use len = VEC_length
too, but IMHO some iteration is helpful, as we don't recurse on them, and we
probably want to handle cases like moving pads across two empty bbs and with a
resx in the third bb or something similar.

[Bug tree-optimization/47290] [4.5/4.6 Regression] memory exhausted compiling a destructor with an infinite 'for (;;);' loop

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47290

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 CC||rth at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-18 
13:50:07 UTC ---
CCing Richard, as he wrote this function...

[Bug tree-optimization/47290] [4.5/4.6 Regression] memory exhausted compiling a destructor with an infinite 'for (;;);' loop

[rth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47290

--- Comment #11 from Richard Henderson rth at gcc dot gnu.org 2011-01-18 
16:45:09 UTC ---
Jakub, I'm fine with your second patch to detect infinite loops, with
the proviso that you break out the test into a separate function.

[Bug tree-optimization/47290] [4.5/4.6 Regression] memory exhausted compiling a destructor with an infinite 'for (;;);' loop

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47290

--- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-18 
17:20:56 UTC ---
Created attachment 23020
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23020
gcc46-pr47290.patch

Like this (still untested but on this testcase)?

[Bug tree-optimization/47290] [4.5/4.6 Regression] memory exhausted compiling a destructor with an infinite 'for (;;);' loop

[rth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47290

--- Comment #13 from Richard Henderson rth at gcc dot gnu.org 2011-01-18 
18:20:49 UTC ---
Looks good.  Ok if it passes tests.

[Bug tree-optimization/47290] [4.5/4.6 Regression] memory exhausted compiling a destructor with an infinite 'for (;;);' loop

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47290

--- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-18 
23:16:18 UTC ---
Author: jakub
Date: Tue Jan 18 23:16:16 2011
New Revision: 168974

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168974
Log:
PR tree-optimization/47290
* tree-eh.c (infinite_empty_loop_p): New function.
(cleanup_empty_eh): Use it.

* g++.dg/torture/pr47290.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr47290.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-eh.c

[Bug tree-optimization/47290] [4.5/4.6 Regression] memory exhausted compiling a destructor with an infinite 'for (;;);' loop

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47290

--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-17 
14:49:53 UTC ---
Created attachment 22995
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22995
gcc46-pr47290.patch

Ugh, cddce pass for empty loop:
L0:

bb 6:
  goto bb 6;

creates a preheader:

L0:

bb 6:

bb 7:
  goto bb 6;

so suddenly we have an empty infinite loop containing two bbs instead of one,
on which cleanup_empty_eh keeps up oscillating between the landing pads on bb 6
and on bb 7 forever.  There is a check already for empty infinite loops, but it
covers just those containing just single bb, not more than that.

I wonder if ehcleanup should be prepared for empty infinite loops containing
arbitrary number of bbs, or if worst case two of them should be possible (that
can be fixed by the attached patch) and why a preheader is created inside of
the loop instead of before it.

[Bug tree-optimization/47290] [4.5/4.6 Regression] memory exhausted compiling a destructor with an infinite 'for (;;);' loop

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47290

--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-17 
15:21:36 UTC ---
Small correction, the empty infinite loop is not split because of preheader
creation, but because of force_single_succ_latches - the condition there causes
edge split even when latch has single succ if header and latch are the same:
if (loop-latch != loop-header  single_succ_p (loop-latch))
  continue;