From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13024 invoked by alias); 1 Oct 2012 15:26:34 -0000 Received: (qmail 12771 invoked by uid 48); 1 Oct 2012 15:26:12 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/54693] VTA guality issues with loops Date: Mon, 01 Oct 2012 15:26: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: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- 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: 2012-10/txt/msg00035.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693 --- Comment #1 from Jakub Jelinek 2012-10-01 15:26:10 UTC --- In VRP it is jump threading that performs the first CFG transformation, and the second one happens as two merge_block opportunities during cleanup_tree_cfg. Doing the new DEBUG stmt insertion upon merge_blocks would be weird, perhaps some pass should just in addition to what it does now try to detect at least the simple cases, where at the end of more than one predecessor block are live debug stmts for some decl, and they use invariants or SSA_NAMEs that appear together in some PHI - then adding a DEBUG stmt at the start of the bb with a PHI might improve debug info quality, something var-tracking won't be able to figure out due to the conditional.