[Bug debug/51570] [4.7 Regression] FAIL: gcc.dg/guality/pr45003-[23].c

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51570

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011-12-16
                 CC|                            |aoliva at gcc dot gnu.org,
                   |                            |jakub at gcc dot gnu.org
     Ever Confirmed|0                           |1

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-12-16 09:08:09 UTC ---
This got "broken" by my ENTRY_VALUE patches, and apparently even Alex'
"Keep static VTA locs in cselib tables only" patch doesn't cure it.

We have:
(debug_insn 6 3 7 2 (var_location:HI D#2 (mem:HI (reg/v/f:DI 5 di [orig:62 p ]
[62]) [0 *p_1(D)+0 S2 A16])) pr45003-3.c:8 -1
     (nil))

(debug_insn 7 6 8 2 (var_location:HI D#1 (debug_expr:HI D#2)) pr45003-3.c:8 -1
     (nil))

(debug_insn 8 7 9 2 (var_location:SI a (sign_extend:SI (debug_expr:HI D#1)))
pr45003-3.c:8 -1
     (nil))

(insn:TI 9 8 10 2 (set (reg:SI 5 di [orig:60 D.1725 ] [60])
        (zero_extend:SI (mem:HI (reg/v/f:DI 5 di [orig:62 p ] [62]) [2
*p_1(D)+0 S2 A16]))) pr45003-3.c:9 117 {*zero_extendhisi2_movzwl}
     (nil))

The PR45003 improvement noted during var-tracking the reverse operation of
(zero_extend:SI (mem:HI (di))))
i.e. that the value of D#2 (and D#1) can be computed as (subreg:HI (reg:SI di))
after insn 9.  Thus before ENTRY_VALUE changes, we'd see that the p pointer
value isn't live after that insn anywhere and the only way to compute it would
be to go back, see that (mem:HI (value of p on entry)) is live in (subreg:HI
(reg:SI di)) and just emit the sign extension of it.
Now, with ENTRY_VALUE, even when we keep it as lowest priority alternative,
we have a place where the value of p on entry is live - (entry_value:DI rdi)
and thus we just use it and don't look further.
This testcase will work just fine with GDB 7.4 which finally supports
DW_OP_GNU_entry_value (just verified that), but that wasn't the actual goal of
the testcase, it is trivial to modify the testcase so that it will fail even
with GDB 7.4:

--- gcc/testsuite/gcc.dg/guality/pr45003-3.c.jj    2010-11-19
20:56:33.000000000 +0100
+++ gcc/testsuite/gcc.dg/guality/pr45003-3.c    2011-12-16 10:01:36.170231171
+0100
@@ -24,8 +24,12 @@ int
 main ()
 {
   unsigned short us = 0x8078;
-  foo (&us);
+  unsigned short *pus = &us;
+  asm volatile ("" : "+r" (pus));
+  foo (pus);
   short s = -32648;
-  bar (&s);
+  short *ps = &s;
+  asm volatile ("" : "+r" (ps));
+  bar (ps);
   return 0;
 }

Then on the call site we don't know what is the value passed to the functions,
and as those values aren't needed afterwards, they aren't saved anywhere.
So, yes, entry_value should have the lowest priority of everything.

To fix this we'd need to cache during vt_emit_notes not just a single
expression, but at most two, one that doesn't use any entry_value expressions
and one that does.  To build the complete expressions for the notes we'd first
try if we can build up an expression entirely without any entry_values, and
only if it fails, supply one with entry_values.  If we did no caching, we could
of course just try to expand twice and ignore entry_value in the first round,
but we really can't avoid the caching, the memory consumption and compile time
complexity was huge on some testcases.