Diego Novillo wrote: > Eric Botcazou wrote on 06/21/06 10:05: > >> It seems to me that the volatility should be accounted for in the >> VALUE_HANDLE >> itself only, not in (de)references to it. >> > As Richard and Andrew pointed out, the bug is that we try to compute the > value number of a statement with volatile references in it. If the > statement is not marked as having volatile references, then it should > be. If the value numbering routines are not checking for volatility, > then they should be.
If the statement has volatile ops, we just give the defs the statement makes (not the virtual defs) unique value numbers, as we should :) if (TREE_CODE (stmt) == MODIFY_EXPR && !ann->has_volatile_ops { ... } else { /* For any other statement that we don't recognize, simply make the names generated by the statement available in AVAIL_OUT and TMP_GEN. */ FOR_EACH_SSA_TREE_OPERAND (op, stmt, iter, SSA_OP_DEF) add_to_sets (op, op, NULL, TMP_GEN (block), AVAIL_OUT (block)); FOR_EACH_SSA_TREE_OPERAND (op, stmt, iter, SSA_OP_USE) add_to_sets (op, op, NULL, NULL , AVAIL_OUT (block)); } Since he's showing us a indirect store or load (which won't show up in the defs list of a statement) being value numbered, the statement must not be marked has_volatile_ops properly. >