[Bug debug/55467] [4.8 Regression] Debug info issues with gcc.dg/guality/pr36728-*.c

["jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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).