------- Comment #7 from rakdver at kam dot mff dot cuni dot cz 2007-11-27
15:04 -------
Subject: Re: [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME
object)
> ------- Comment #6 from jakub at gcc dot gnu dot org 2007-11-27 14:17 -------
> I've changed that
> + if (gimplify_ctxp->allow_rhs_cond_expr
> + && !TREE_SIDE_EFFECTS (*expr_p)
> + && expression_without_side_effects_p (*expr_p))
> + return gimplify_pure_cond_expr (expr_p, pre_p);
> into
> + if (gimplify_ctxp->allow_rhs_cond_expr
> + && !TREE_SIDE_EFFECTS (*expr_p))
> + {
> + gcc_assert (expression_without_side_effects_p (*expr_p));
> + return gimplify_pure_cond_expr (expr_p, pre_p);
> + }
> and so far haven't found any failure, so perhaps recalculate_side_effects
> wouldn't be needed. Or, was there any specific reason why TREE_SIDE_EFFECTS
> wasn't enough or was incorrect?
I think the problems only appeared if allow_rhs_cond_expr was enabled
for the gimplification pass (when called from the loop optimizer,
the expressions passed to gimplifier do not have any side effects,
so you would not detect any problem even if you removed the
TREE_SIDE_EFFECTS check).
> BTW, regarding the original rationale of the patch, to represent the number of
> iterations of a do ... while loop you could use also MAX_EXPR <1, n> and
> that's
> gimple already accepted by force_gimple_operand even without the patch.
yes, although making it work that way is more complicated; it would require
changes in the # of iterations analysis, to get
1000 + (unsigned) MAX_EXPR (-1000, n)
for
for (i = -1000; i < n; i++)
while we already have all the information necessary to produce
n >= -1000 ? 1000 + (unsigned) n : 0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34005
