The following code causes an ICE when compiled with the current gcc trunk at -O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes. It is a regression from 5.2.x. $ gcc-trunk -v Using built-in specs. COLLECT_GCC=gcc-trunk COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk --enable-languages=c,c++ --disable-werror --enable-multilib Thread model: posix gcc version 6.0.0 20151122 (experimental) [trunk revision 230719] (GCC) $ $ gcc-trunk -O2 -c small.c $ gcc-5.2 -O3 -c small.c $ $ gcc-trunk -O3 -c small.c small.c: In function ‘fn2’: small.c:10:1: internal compiler error: in quick_push, at vec.h:845 } ^ 0xac60d2 vec<basic_block_def*, va_heap, vl_embed>::quick_push(basic_block_def* const&) ../../gcc-trunk/gcc/vec.h:845 0xac60d2 vec<basic_block_def*, va_heap, vl_ptr>::quick_push(basic_block_def* const&) ../../gcc-trunk/gcc/vec.h:1503 0xac60d2 try_shrink_wrapping(edge_def**, bitmap_head*, rtx_insn*) ../../gcc-trunk/gcc/shrink-wrap.c:714 0x870058 thread_prologue_and_epilogue_insns() ../../gcc-trunk/gcc/function.c:6021 0x870a92 rest_of_handle_thread_prologue_and_epilogue ../../gcc-trunk/gcc/function.c:6543 0x870a92 execute ../../gcc-trunk/gcc/function.c:6585 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. $ ------------------------------ int a, b, c, d; void fn2 () { if (c) for (; d; d = a+b) for (c = 0; c < 2; c++) fn2 (); }
Confirmed.
Started with r227775: commit 5c2b6d9bed3b944469ab387325476d1188000f46 Author: segher <segher@138bc75d-0d04-0410-961f-82ee72b054a4> Date: Tue Sep 15 00:38:21 2015 +0000 shrink-wrap: Rewrite
Confirmed, mine.
Author: segher Date: Tue Nov 24 21:23:25 2015 New Revision: 230843 URL: https://gcc.gnu.org/viewcvs?rev=230843&root=gcc&view=rev Log: 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. Modified: trunk/gcc/ChangeLog trunk/gcc/shrink-wrap.c
Fixed. Thanks for the report!