From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10147 invoked by alias); 5 May 2010 20:03:22 -0000 Received: (qmail 8640 invoked by uid 48); 5 May 2010 20:02:43 -0000 Date: Wed, 05 May 2010 20:03:00 -0000 Message-ID: <20100505200243.8639.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug debug/43983] var-tracking needlessly throws away location info for SRAed vars In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "rguenth 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-05/txt/msg00482.txt.bz2 ------- Comment #4 from rguenth at gcc dot gnu dot org 2010-05-05 20:02 ------- (In reply to comment #3) > Two issues discovered with the patch. One is easy: > --- gcc/dwarf2out.c 2010-05-05 17:14:56.000000000 +0200 > +++ gcc/dwarf2out.c 2010-05-05 20:51:40.000000000 +0200 > @@ -7916,7 +7916,7 @@ > { > rtx piece = *piece_loc; > diff -= decl_piece_bitsize (piece); > - piece_loc = &XEXP (piece, 1); > + *piece_loc = XEXP (piece, 1); > free_EXPR_LIST_node (piece); > } > /* Add padding if needed. */ > > The other shows on various libgcc files with -m32 - apparently SRA leaves > sometimes the original decl in the IL together with SRAed variables, the patch > assumed that either the SRAed variables, or the original appear, but not both. It indeed happens on purpose. We in some cases re-build the aggregate for aggregate uses. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43983