http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48150
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-11-24
14:44:57 UTC ---
Yeah, can't reproduce -O2/-O3/-Os issues, but can reproduce
FAIL: gcc.dg/guality/sra-1.c -O1 line 43 a.i == 4
FAIL: gcc.dg/guality/sra-1.c -O1 line 43 a.j == 14
with gdb-7.3.50.20110722-10.fc16.x86_64.
With
GUALITY_GDB_NAME=/usr/src/gdb/obj/gdb/gdb \
make check-gcc RUNTESTFLAGS='guality.exp=sra-1.c'
where that gdb is current trunk gdb I can't reproduce it though, entry_value
works for that case well.
line 43 a.i == 4 test I'd assume it would work fine with latest trunk gdb even
if no entry_value could be looked up:
4004fb: e8 74 ff ff ff callq 400474 <bar>
400500: c1 e3 04 shl $0x4,%ebx
400503: 83 c3 70 add $0x70,%ebx
400506: 66 c1 fb 04 sar $0x4,%bx
40050a: 0f bf db movswl %bx,%ebx
40050d: 89 df mov %ebx,%edi
40050f: e8 60 ff ff ff callq 400474 <bar>
with
000002c2 00000000004004fb 00000000004004ff (DW_OP_bit_piece: size: 4
offset: 0 ; DW_OP_reg0 (rax); DW_OP_bit_piece: size: 12 offset: 0 ; DW_OP_breg3
(rbx): 7; DW_OP_stack_value; DW_OP_bit_piece: size: 12 offset: 0 ;
DW_OP_bit_piece: size: 4 offset: 0 )
000002c2 00000000004004ff 0000000000400503 (DW_OP_bit_piece: size: 4
offset: 0 ; DW_OP_reg6 (rbp); DW_OP_bit_piece: size: 12 offset: 0 ; DW_OP_breg3
(rbx): 7; DW_OP_stack_value; DW_OP_bit_piece: size: 12 offset: 0 ;
DW_OP_bit_piece: size: 4 offset: 0 )
000002c2 0000000000400503 0000000000400521 (DW_OP_bit_piece: size: 4
offset: 0 ; DW_OP_reg6 (rbp); DW_OP_bit_piece: size: 12 offset: 0 ;
DW_OP_GNU_entry_value: (DW_OP_reg5 (rdi)); DW_OP_plus_uconst: 7;
DW_OP_stack_value; DW_OP_bit_piece: size: 12 offset: 0 ; DW_OP_bit_piece: size:
4 offset: 0 )
000002c2 0000000000400521 0000000000400526 (DW_OP_piece: 2;
DW_OP_GNU_entry_value: (DW_OP_reg5 (rdi)); DW_OP_plus_uconst: 7;
DW_OP_stack_value; DW_OP_bit_piece: size: 12 offset: 0 ; DW_OP_bit_piece: size:
4 offset: 0 )
000002c2 <End of list>
doesn't work with older gdb just because there is the unhandled
DW_OP_GNU_entry_value in the expression and gdb gives up even when it doesn't
affect the a.i bitfield part which lives properly in low bits of $rbp.
The line 43 a.j == 14 case is much more complicated at -O1. The problem is
that
we have 12-bit precision arithmetics done for -O1 and thus we end up with:
(debug_insn 14 13 15 2 (var_location:HI a$j (plus:HI (subreg:HI (reg/v:SI 3 bx
[orig:69 k ] [69]) 0)
(const_int 7 [0x7]))) sra-1.c:41 -1
(nil))
...
(insn 40 18 20 2 (parallel [
(set (reg:SI 3 bx [73])
(ashift:SI (reg:SI 3 bx [orig:69 k ] [69])
(const_int 4 [0x4])))
(clobber (reg:CC 17 flags))
]) sra-1.c:39 499 {*ashlsi3_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
...
(insn 41 21 23 2 (parallel [
(set (reg:SI 3 bx [76])
(plus:SI (reg:SI 3 bx [73])
(const_int 112 [0x70])))
(clobber (reg:CC 17 flags))
]) sra-1.c:41 253 {*addsi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 23 41 24 2 (parallel [
(set (reg:HI 3 bx [77])
(ashiftrt:HI (reg:HI 3 bx [76])
(const_int 4 [0x4])))
(clobber (reg:CC 17 flags))
]) sra-1.c:41 543 {*ashrhi3_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 24 23 25 2 (set (reg:SI 3 bx [orig:65 D.2953 ] [65])
(sign_extend:SI (reg:HI 3 bx [77]))) sra-1.c:43 128 {extendhisi2}
(nil))
And var-tracking works on VALUEs with modes, not on weirdo precision types.
If var-tracking would track somehow that it is only interested in low 12 bits
of the value, then it could throgh the above insns figure out that those 12
bits
are first shifted up by 4, then 112 added and then shifted down by 4, thus
low 12 bits of bx in the end contain the right 12 bits with 7 added to it.
