From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17406 invoked by alias); 28 Nov 2011 15:33:13 -0000 Received: (qmail 17392 invoked by uid 22791); 28 Nov 2011 15:33:12 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_TM 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; Mon, 28 Nov 2011 15:32:59 +0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/50317] [4.7 Regression] missing DW_OP_GNU_implicit_pointer Date: Mon, 28 Nov 2011 15:41: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/msg02668.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50317 --- Comment #11 from Jakub Jelinek 2011-11-28 15:32:18 UTC --- (In reply to comment #10) > (In reply to comment #8) > > Perhaps we could drop the var ={v} {CLOBBER} stmts when renaming the var > > into SSA instead. > > I think your current patch is better, no use in slowing down the SSA renamer, > there aren't that many points where a var can suddenly become renamed > when it couldn't before. I think you should send it to gcc-patches > independent if it fixes this one or not. Yeah, I played with it and doing it in the renamer wouldn't be very trivial and very surprising for various passes if the renamer removes stmts. Will bootstrap/regtest it. > > As for gcc47-pr50317-1.patch, the another walk isn't because of the > > CLOBBERs, what it tries to solve is drop the ADDRESSABLE bit before > > CDDCE decides to instead optimize all the stores away as unnecessary > > (the former does the right thing for debug info, the latter does not). > > But conceivably we can have other passes than CDDCE which can remove > stores, including the last one, so IMO the latter should better be made to > work. As in, update_address_taken should purely be an optimization, it should > never be required for correct operation. Well, the another scheduled in updates_address_taken wasn't a correctness issue, just a nice to have thing which improves debug info in that case. The debug info isn't incorrect, just less complete (and the regression is in the debug info quality). > Okay, so there are multiple ways out: > 1) accept also TREE_ADDRESSABLES in target_for_debug_bind; > why is it rejecting the needs_to_live_in_memory objects? > 2) drop TREE_ADDRESSABLE for unreferenced variables > (remove_unused_locals, but that again should only be an optimization, > not a correctness measure) > 3) Accept variables in DEBUG_BIND unconditionally if they are > target_for_debug_bind or not. Presumably the one creating the debug > bind will have known what he was doing. > > I think (3) looks most sensible? What I have in the last patch is roughly accepting those TREE_ADDRESSABLES in there while in GIMPLE IL (== 1) ), dropping TREE_ADDRESSABLE in remove_unused_locals as an optimization (== 2) ) and avoiding creation of the debug insns during expansion if they don't still satisfy target_for_debug_bind (correctness issue).