From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18502 invoked by alias); 24 Nov 2011 14:45:47 -0000 Received: (qmail 18492 invoked by uid 22791); 24 Nov 2011 14:45:45 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 24 Nov 2011 14:45:31 +0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/48150] [4.7 Regression] gcc.dg/guality/sra-1.c Date: Thu, 24 Nov 2011 15:00:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: debug X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.7.0 X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-11/txt/msg02411.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48150 --- Comment #6 from Jakub Jelinek 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 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 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 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.