http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55467
Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aoliva at gcc dot gnu.org --- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-11-27 09:44:32 UTC --- Or perhaps better just follow what we do at the end of basic blocks in var-tracking: --- gcc/cselib.c.jj 2012-11-26 10:14:26.000000000 +0100 +++ gcc/cselib.c 2012-11-27 10:29:23.524991980 +0100 @@ -2632,6 +2632,8 @@ cselib_process_insn (rtx insn) || (NONJUMP_INSN_P (insn) && volatile_insn_p (PATTERN (insn)))) { + if (cselib_preserve_constants) + cselib_preserve_only_values (); cselib_reset_table (next_uid); cselib_current_insn = NULL_RTX; return; That will also clear REG/MEMs from VALUEs that we drop from the hash table. But there is another, unrelated, issue, that regressed with the r193802 commit. In main of the new testcases, or even just int foo (int arg1, int arg2, int arg3, int arg4, int arg5, int arg6, int arg7); int main () { int l = 0; asm volatile ("" : "=r" (l) : "0" (l)); foo (l + 1, l + 2, l + 3, l + 4, l + 5, l + 6, l + 30); return 0; } alone for e.g. -g -O2 -m32, since that commit we now emit wrong call site info, saying that e.g. the first argument has call_site_value of %eax + 1, which is wrong, as %eax is call clobbered register. I'd have expected that case MO_CALL: dataflow_set_clear_at_call (set); should have cleared the %eax location from all the VALUEs, as %eax is call clobbered. With the cselib.c patch in this comment as opposed to the cselib.c in the attached patch the call site info is also wrong, but differently (instead of saying that the value is say %eax + 1 it now says it is 1 (it is correct only because the inline asm hasn't changed it to non-zero, but the compiler can't rely on that).