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),
