From patchwork Wed Jan 16 16:13:47 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Fix loop-iv.c ICE From: Jan Hubicka X-Patchwork-Id: 212793 Message-Id: <20130116161346.GB3955@kam.mff.cuni.cz> To: gcc-patches@gcc.gnu.org Date: Wed, 16 Jan 2013 17:13:47 +0100 Hi, this patch fixes ICE seen in PR51083 on PPC. Here the flags ^= 0x80000000 expression is translated as PLUS. This makes us to consider flags to be IV and work out that the loop do not really iterate. It is a missed optimization that we do not work out this on all targets and do not unloop the loop at tree level. I opened PR for this. This patch fixes the ICE that we get confused on concluding that max number of iterations is 0. Bootstrapped/regtested x86_64-linux (where the code path do not really trigger obviously) and tested that it is fixing the testcase on PPC. OK? Honza PR tree-optimizatoin/51083 * gcc.c-torture/compile/pr51083.c: New testcase. * loop-iv.c (iv_number_of_iterations): Consider zero iteration case. Index: testsuite/gcc.c-torture/compile/pr51083.c =================================================================== --- testsuite/gcc.c-torture/compile/pr51083.c (revision 0) +++ testsuite/gcc.c-torture/compile/pr51083.c (revision 0) @@ -0,0 +1,18 @@ +extern int debug_threads; +extern void sigsuspend (void); +void my_waitpid (int flags, int wnohang) +{ + while (1) + { + if (flags & 0x80000000) + { + if (wnohang) + break; + if (debug_threads) + __builtin_puts ("blocking\n"); + sigsuspend (); + } + flags ^= 0x80000000; + } +} + Index: loop-iv.c =================================================================== --- loop-iv.c (revision 195144) +++ loop-iv.c (working copy) @@ -2819,7 +2819,8 @@ iv_number_of_iterations (struct loop *lo else { max = determine_max_iter (loop, desc, old_niter); - gcc_assert (max); + if (!max) + goto zero_iter_simplify; if (!desc->infinite && !desc->assumptions) record_niter_bound (loop, double_int::from_uhwi (max),