This is the mail archive of the 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]

Re: asm goto vs simulate_block

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

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.


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

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