From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10280 invoked by alias); 20 Jul 2010 10:40:33 -0000 Received: (qmail 10162 invoked by uid 48); 20 Jul 2010 10:40:11 -0000 Date: Tue, 20 Jul 2010 10:40:00 -0000 Message-ID: <20100720104011.10161.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug ada/45003] VTA issues with sign/zero extension and debug temporaries In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "jakub at gcc dot gnu dot org" 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: 2010-07/txt/msg02034.txt.bz2 ------- Comment #1 from jakub at gcc dot gnu dot org 2010-07-20 10:40 ------- /* PR debug/45003 */ /* { dg-do run { target { x86_64-*-* && lp64 } } } */ /* { dg-options "-g" } */ int __attribute__((noinline)) foo (unsigned short *p) { int a = *p; asm volatile ("nop" : : "D" ((int) *p)); asm volatile ("nop" : : "D" ((int) *p));/* { dg-final { gdb-test 10 "a" "0x8078" } } */ return 0; } int __attribute__((noinline)) bar (short *p) { unsigned int a = *p; asm volatile ("nop" : : "D" ((unsigned int) *p)); asm volatile ("nop" : : "D" ((unsigned int) *p));/* { dg-final { gdb-test 19 "a" "-32648" } } */ return 0; } int main () { unsigned short us = 0x8078; foo (&us); short s = -32648; bar (&s); return 0; } There are two problems. One is that in DEBUG_INSN we use wrong extension (in foo SIGN_EXTEND instead of ZERO_EXTEND, in bar the other way around). The second issue is that debug temporaries prevent us to see that the value actually is still live in the %edi register, because one VALUE is used for (zero_extend:SI (debug_expr:HI D#1)) and another one for (zero_extend:SI (mem:HI (...)) where the debug temporary is the MEM. For the second issue, one possibility would be to find debug temporaries that are set just once and use their associated VALUE directly instead of the DEBUG_EXPR. The other possibility would be if we see that SIGN_EXTEND or ZERO_EXTEND of something is loaded into a register, note not just that the SIGN_EXTEND/ZERO_EXTEND VALUE lives in that register, but also that the operand's VALUE lives in the low part of that register. Alex, what do you think? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45003