https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62175
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ok, so we try to generate a memset from a loop with the number of iterations
being
(long int) (_3 + 1) >= (long int) _7 + 1 ? ((unsigned long) (_3 + 1) -
(unsigned long) _7) - 1 : 0
as this has conditionals it doesn't survive gimplification (gimplification
turns it into control-flow).
Not sure how other passes avoid running into this.
We run into this gimplifying issue because of:
if (gimplify_ctxp->allow_rhs_cond_expr
/* If either branch has side effects or could trap, it can't be
evaluated unconditionally. */
&& !TREE_SIDE_EFFECTS (then_)
&& !generic_expr_could_trap_p (then_)
&& !TREE_SIDE_EFFECTS (else_)
&& !generic_expr_could_trap_p (else_))
return gimplify_pure_cond_expr (expr_p, pre_p);
that is, gimplification is afraid of evaluating both COND_EXPR results
unconditionally because of -ftrapv.
[of course those are compiler-generated expressions and shouldn't have
-ftrapv applied, but that's not possible to tell right now so it would
mean creating unsigned expressions only]
Here _3 + 1 can trap.
We could short-cicuit the above by gimplify_ctxp->into_ssa but that may
cause these ICEs to turn into wrong-code if we ever bogously generate
trapping expressions unconditonally.
It is tree-ssa-loop-niter.c:expand_simple_operations which builds up this
expression. We could guard that properly to not expand possibly trapping
statements. That's probably the safest and most reliable way of avoiding
this bug.
Index: gcc/tree-ssa-loop-niter.c
===================================================================
--- gcc/tree-ssa-loop-niter.c (revision 214258)
+++ gcc/tree-ssa-loop-niter.c (working copy)
@@ -1633,6 +1633,9 @@ expand_simple_operations (tree expr)
case PLUS_EXPR:
case MINUS_EXPR:
+ if (TYPE_OVERFLOW_TRAPS (TREE_TYPE (expr)))
+ return expr;
+ /* Fallthru. */
case POINTER_PLUS_EXPR:
/* And increments and decrements by a constant are simple. */
e1 = gimple_assign_rhs2 (stmt);
