This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/34005] [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME object)



------- Comment #13 from rakdver at kam dot mff dot cuni dot cz  2007-11-28 13:45 -------
Subject: Re:  [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME
object)

> ------- Comment #12 from jakub at gcc dot gnu dot org  2007-11-28 13:20 -------
> So, shouldn't the expression_without_side_effects_p routine just be renamed
> to expression_could_trap_p, otherwise it will be confused again and again with
> !TREE_SIDE_EFFECTS on the expr?  The gimplify_cond_expr new hunk then could be
> +       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 (TREE_OPERAND (*expr_p, 1))
> +           && !expression_could_trap_p (TREE_OPERAND (*expr_p, 1))
> +           && !TREE_SIDE_EFFECTS (TREE_OPERAND (*expr_p, 2))
> +           && !expression_could_trap_p (TREE_OPERAND (*expr_p, 2)))
> +         return gimplify_pure_cond_expr (expr_p, pre_p);
> 
> This would allow side effects on condition of the COND_EXPR, and at least to me
> would be less confusing (and given that Diego raised that question first, I'm
> probably not alone).

that would be fine with me (it would be safer than changing the
semantics of TREE_SIDE_EFFECTS).  I guess it is up to Diego,
I am willing to do it either way.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34005


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]