Re: asm goto vs simulate_block

[Richard Henderson <rth at redhat dot com>]

> My guess, witjout seeing the testcase.
> In ccp_initialize we have:
>
>       for (i = gsi_start_bb (bb); !gsi_end_p (i); gsi_next (&i))
>         {
>           gimple stmt = gsi_stmt (i);
>           bool is_varying = surely_varying_stmt_p (stmt);
>
>           if (is_varying)
>             {
>               tree def;
>               ssa_op_iter iter;
>
>               /* If the statement will not produce a constant, mark
>                  all its outputs VARYING.  */
>               FOR_EACH_SSA_TREE_OPERAND (def, stmt, iter, SSA_OP_ALL_DEFS)
>                 set_value_varying (def);
>             }
>           prop_set_simulate_again (stmt, !is_varying);
>
> This code looks clearly broken if the statement is control altering
> (like your asm), since it will cause us to never simulate it and add
> the outgoing edges (since the outgoing edges are only added in
> simulate_stmt).

Your guess is absolutely correct.  We already correctly
handle this case in init_copy_prop, but do not in two
other places.

And I just ran into this with my exception rewrite too,
which has an EH_DISPATCH control statement with multiple
normal edges plus a fallthru.  The only thing "weird"
about this statement is that it has multiple normal edges
and nothing currently visible in the program that determines
which edge will be taken.

The following patch appears to work for both.  I'll commit
it after a bootstrap and test cycle completes.


r~

Attachment: d-asmgoto-5b
Description: Text document