shrink-wrap: Fix thinko (PR68520)
commit18b6450a774e13b6381b6a49b0adcf40c2c7e6a3
authorsegher <segher@138bc75d-0d04-0410-961f-82ee72b054a4>
Tue, 24 Nov 2015 21:23:25 +0000 (24 21:23 +0000)
committersegher <segher@138bc75d-0d04-0410-961f-82ee72b054a4>
Tue, 24 Nov 2015 21:23:25 +0000 (24 21:23 +0000)
tree1445a123125a0829b42a3d6c4cd0f912707bbf35
parentc954a5bd02fef8811c184aa60f525b9bc5e30487
shrink-wrap: Fix thinko (PR68520)

Part of the shrink-wrapping algorithm has this comment:

  /* Now see if we can put the prologue at the start of PRO.  Putting it
     there might require duplicating a block that cannot be duplicated,
     or in some cases we cannot insert the prologue there at all.  If PRO
     wont't do, try again with the immediate dominator of PRO, and so on.

     The blocks that need duplicating are those reachable from PRO but
     not dominated by it.  We keep in BB_WITH a bitmap of the blocks
     reachable from PRO that we already found, and in VEC a stack of
     those we still need to consider (to find successors).  */

Two of the cases that push to that stack do not actually check the
bitmap first.  Either I thought those blocks could not be on the stack
already, or more likely I didn't think and it just didn't crash during
any testing.  But of course those blocks *can* already be on the stack
(if you have a hideous loop structure), and then we end up with the
same block on the stack more than once.  This is harmless, except that
(like in the PR) this can overflow the stack.

This fixes it, by doing the necessary bitmap checks before pushing.

PR rtl-optimization/68520
* shrink-wrap.c (try_shrink_wrapping): Don't push a block to VEC if
its bit was already set in BB_WITH.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@230843 138bc75d-0d04-0410-961f-82ee72b054a4
gcc/ChangeLog
gcc/shrink-wrap.c