[Bug debug/47624] New: FAIL: gcc.dg/guality/pr43077-1.c -O1 line 42 c == 3

[Bug debug/47624] New: FAIL: gcc.dg/guality/pr43077-1.c -O1 line 42 c == 3

[schwab@linux-m68k.org]

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

           Summary: FAIL: gcc.dg/guality/pr43077-1.c  -O1  line 42 c == 3
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: schwab@linux-m68k.org
            Target: powerpc*-*-*


Breakpoint 1, fn3 ()
    at /daten/gcc/gcc-20110206/gcc/testsuite/gcc.dg/guality/pr43077-1.c:44
44      }
(gdb) i addr c
Symbol "c" is a complex DWARF expression:
     1: DW_OP_breg4 12 [$r4]
.
(gdb) disass
Dump of assembler code for function fn3:
   0x100004e0 <+0>:     stwu    r1,-32(r1)
   0x100004e4 <+4>:     mflr    r0
   0x100004e8 <+8>:     stw     r0,36(r1)
   0x100004ec <+12>:    li      r0,0
   0x100004f0 <+16>:    stw     r0,8(r1)
   0x100004f4 <+20>:    mr      r4,r1
   0x100004f8 <+24>:    stwu    r0,12(r4)
   0x100004fc <+28>:    addi    r3,r1,8
   0x10000500 <+32>:    bl      0x100004c4 <foo>
=> 0x10000504 <+36>:    lwz     r0,36(r1)
   0x10000508 <+40>:    mtlr    r0
   0x1000050c <+44>:    addi    r1,r1,32
   0x10000510 <+48>:    blr
End of assembler dump.

c is not at $r4+12 but at $r4+0 (or $r1+12) because $r4 has been incremented
when the value was stored.

[Bug debug/47624] FAIL: gcc.dg/guality/pr43077-1.c -O1 line 42 c == 3

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-02-07 11:42:28 UTC ---
In the .optimized dump I see the exact same IL with/without -flto (yes,
including debug stmts and locations).

[Bug debug/47624] FAIL: gcc.dg/guality/pr43077-1.c -O1 line 42 c == 3

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.02.07 13:08:13
                 CC|                            |aoliva at gcc dot gnu.org,
                   |                            |jakub at gcc dot gnu.org
     Ever Confirmed|0                           |1

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-02-07 13:08:13 UTC ---
Yeah, this looks like a var-tracking bug.
We have:

(insn 32 7 9 2 (set (reg/f:DI 4 4 [127])
        (reg/f:DI 1 1)) pr43077-1.c:34 358 {*movdi_internal64}
     (expr_list:REG_EQUAL (reg/f:DI 1 1)
        (nil)))

which adjust_insn transforms into:

(insn 32 7 9 2 (set (reg/f:DI 4 4 [127])
        (plus:DI (reg/f:DI 67 ap)
            (const_int -128 [0xffffffffffffff80]))) pr43077-1.c:34 358
{*movdi_internal64}
     (expr_list:REG_EQUAL (reg/f:DI 1 1)
        (nil)))

and:

(insn 9 32 31 2 (set (mem/c/i:DI (pre_modify:DI (reg/f:DI 4 4 [127])
                (plus:DI (reg/f:DI 4 4 [127])
                    (const_int 120 [0x78]))) [0 c+0 S8 A64])   
        (reg:DI 0 0 [125])) pr43077-1.c:34 358 {*movdi_internal64}
     (expr_list:REG_DEAD (reg:DI 0 0 [125])
        (expr_list:REG_INC (reg/f:DI 4 4 [127])
            (nil))))

which is adjusted into:

(insn 9 32 31 2 (parallel [
            (set (mem/c/i:DI (plus:DI (reg/f:DI 4 4 [127])
                        (const_int 120 [0x78])) [0 c+0 S8 A64])
                (reg:DI 0 0 [125]))  
            (set (reg/f:DI 4 4 [127])
                (plus:DI (reg/f:DI 4 4 [127])
                    (const_int 120 [0x78])))
        ]) pr43077-1.c:34 358 {*movdi_internal64}
     (expr_list:REG_DEAD (reg:DI 0 0 [125])
        (expr_list:REG_INC (reg/f:DI 4 4 [127])
            (nil))))

I believe that is correct.  Now, for the latter insn, we get following uops:
bb 2 op 12 insn 9 MO_USE_NO_VAR (reg/f:DI 4 4 [127])
bb 2 op 13 insn 9 MO_USE_NO_VAR (reg:DI 0 0 [125])
bb 2 op 14 insn 9 MO_USE_NO_VAR (reg/f:DI 4 4 [127])
bb 2 op 15 insn 9 MO_VAL_SET (concat/u/i:DI (concat:DI (value/u:DI 7:7851
@0x2fb62b0/0x2fb6150)
            (reg/f:DI 4 4 [127]))
        (concat:DI (value/u:DI 4:3802 @0x2fb6268/0x2fb60c0)
            (plus:DI (value/u:DI 7:7851 @0x2fb62b0/0x2fb6150)
                (const_int -120 [0xffffffffffffff88]))))
bb 2 op 16 insn 9 MO_VAL_SET (concat (concat:DI (value/u:DI 5:3870
@0x2fb6280/0x2fb60f0)
            (mem/c/i:DI (value/u:DI 7:7851 @0x2fb62b0/0x2fb6150) [0 cD.1258+0
S8 A64]))
        (set (mem/c/i:DI (plus:DI (reg/f:DI 4 4 [127])
                    (const_int 120 [0x78])) [0 cD.1258+0 S8 A64])
            (reg:DI 0 0 [125])))
In the last uop, we have VAL_HOLDS_TRACK_EXPR set and no other flags.  As c is
only ever mentioned in MEM_ATTRS, the raw r4 + 120 address is used as its
location instead of tracking its value, and furthermore it doesn't even take
into account that r4 has been incremented in the very same insn and thus right
after the insn it is (mem (reg 4)) anyway.
Not sure why we don't value track the mem's address even for decls mentioned in
MEM_ATTRS (i.e. why the MEM doesn't use a VALUE as the address), that IMHO
would magically fix this.  We would even figure out c is stored into a fbreg
based loc.  Adding manually (in the debugger) a
@@ -5383,6 +5383,7 @@ add_stores (rtx loc, const_rtx expr, voi
          if (GET_CODE (expr) == SET && SET_DEST (expr) == loc)
            src = var_lowpart (mode2, SET_SRC (expr));
          loc = var_lowpart (mode2, loc);
+if (type == MO_VAL_SET) loc = replace_expr_with_values (loc);

          if (src == NULL)
            {
call partly fixes the testcase, c is not claimed to be at r4 + 120 anymore, but
at r4, which is correct at that spot; the following call to foo makes r4
register dead though, and so during and after the call the location info for c
is not valid anymore.
We could try harder and say canonicalize in cselib locs of the form
(plus (value X) (const_int N)) (or minus) where (value X) has locs
(plus cfa_base_preserved_val->v_val_rtx (const_int M)) into
a (plus cfa_base_preserved_val->v_val_rtx (const_int M+N)) and then we'd figure
out that r4 + 120 here is actually ap + offset and could even use a hardcoded,
non-value related, ap + offset location in this case.  But we also need to
figure out what to do in a more general case.  Alex, ideas?
Not a 4.6 material though.

[Bug debug/47624] FAIL: gcc.dg/guality/pr43077-1.c -O1 line 42 c == 3

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva <aoliva at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |aoliva at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #3 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2011-02-14 11:26:44 UTC ---
Mine

[Bug debug/47624] FAIL: gcc.dg/guality/pr43077-1.c -O1 line 42 c == 3

[aoliva at gcc dot gnu.org]

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

--- Comment #4 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2011-02-20 02:19:42 UTC ---
Patch is at http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00981.html

Deferred to 4.7.

[Bug debug/47624] FAIL: gcc.dg/guality/pr43077-1.c -O1 line 42 c == 3

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-05-19 10:40:13 UTC ---
Can you please ping this patch?

[Bug debug/47624] FAIL: gcc.dg/guality/pr43077-1.c -O1 line 42 c == 3

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva <aoliva at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |49888

--- Comment #6 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2012-05-23 09:28:16 UTC ---
An updated patch is at http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01320.html

The patch for bug 49888 depends on it.

[Bug debug/47624] FAIL: gcc.dg/guality/pr43077-1.c -O1 line 42 c == 3

[aoliva at gcc dot gnu.org]

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

--- Comment #7 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2012-06-13 21:43:24 UTC ---
Author: aoliva
Date: Wed Jun 13 21:43:19 2012
New Revision: 188530

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188530
Log:
PR debug/47624
* var-tracking.c (loc_exp_dep_pool): New.
(vt_emit_notes): Create and release the pool.
(compute_bb_dataflow): Use value-based locations in MO_VAL_SET.
(emit_notes_in_bb): Likewise.
(loc_exp_dep_insert): Deal with NOT_ONEPART vars.
(notify_dependents_of_changed_value): Likewise.
(notify_dependents_of_resolved_value): Check that NOT_ONEPART
variables don't have a VAR_LOC_DEP_LST.
(emit_note_insn_var_location): Expand NOT_ONEPART locs that are
VALUEs or MEMs of VALUEs.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/var-tracking.c

[Bug debug/47624] FAIL: gcc.dg/guality/pr43077-1.c -O1 line 42 c == 3

[aoliva at gcc dot gnu.org]

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

--- Comment #8 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2012-06-13 21:49:09 UTC ---
Fixed on trunk.  I'm going to look into backporting it.

[Bug debug/47624] FAIL: gcc.dg/guality/pr43077-1.c -O1 line 42 c == 3

[ubizjak at gmail dot com]

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

--- Comment #9 from Uros Bizjak <ubizjak at gmail dot com> 2012-06-17 17:01:42 UTC ---
(In reply to comment #8)
> Fixed on trunk.  I'm going to look into backporting it.

This patch caused PR53706.

[Bug debug/47624] FAIL: gcc.dg/guality/pr43077-1.c -O1 line 42 c == 3

[aoliva at gcc dot gnu.org]

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

--- Comment #10 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2012-06-28 07:39:59 UTC ---
Author: aoliva
Date: Thu Jun 28 07:39:51 2012
New Revision: 189037

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189037
Log:
PR debug/53706
PR debug/47624
* var-tracking.c (vt_emit_notes): Release loc_exp_dep_pool...
(vt_finalize): ... here instead, if needed.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/var-tracking.c

[Bug debug/47624] FAIL: gcc.dg/guality/pr43077-1.c -O1 line 42 c == 3

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva <aoliva at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #10 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2012-06-28 07:39:59 UTC ---
Author: aoliva
Date: Thu Jun 28 07:39:51 2012
New Revision: 189037

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189037
Log:
PR debug/53706
PR debug/47624
* var-tracking.c (vt_emit_notes): Release loc_exp_dep_pool...
(vt_finalize): ... here instead, if needed.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/var-tracking.c

--- Comment #11 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2012-11-08 03:01:08 UTC ---
Fixed.  Not backporting.