Re: [tuples][patch] Don't create GIMPLE_CONDs that trap

["Richard Guenther" <richard dot guenther at gmail dot com>]

On Fri, May 2, 2008 at 3:16 PM, Rafael Espindola <espindola@google.com> wrote:
> The attached patch fixes the problem we were having with a BB having
>  more than 2 output edges. It includes a fix for the problem Doug's
>  observed on tree_could_trap_p.
>
>  OK if it bootstraps and passes regression tests.
>
>  * tree-eh.c (tree_could_trap_p): Look at the first operand of a
>  comparison to find if we have a floating point op.
>  * gimplify.c (gimplify_cond_expr): If a comparison traps, put it in a
>  GIMPLE_ASSIGN.

I don't know how gimplification is different on the tuples branch, but
shouldn't just adjusting the is_gimple_condexpr predicate to

bool
is_gimple_condexpr (tree t)
{
  return (is_gimple_val (t)
            || (COMPARISON_CLASS_P (t)
                && !tree_could_trap_p (t)));
}

be sufficient to fix the problem there (and on the mainline)?

Please also fix this on the mainline (even though I realize that
tree_could_trap_p has diverged in tuples).

Thanks,
Richard.