From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23741 invoked by alias); 10 Jul 2008 12:02:04 -0000 Received: (qmail 23386 invoked by uid 48); 10 Jul 2008 12:01:15 -0000 Date: Thu, 10 Jul 2008 12:02:00 -0000 Message-ID: <20080710120115.23385.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug debug/36690] [4.3/4.4 Regression] .debug_line first line is behind the first instruction 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: 2008-07/txt/msg01005.txt.bz2 ------- Comment #3 from jakub at gcc dot gnu dot org 2008-07-10 12:01 ------- Created an attachment (id=15888) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15888&action=view) gcc44-pr36690.patch Unfinished patch which solves the testcase in this PR and a couple of other problems, but still there are plenty of issues. It adds goto_block field to edges, because sometimes an edge is the only place that uses certain scope. Consider say: void bar (int); void foo (int i) { if (!i) bar (0); else { static int z = 5; goto f1; } bar (1); f1: bar (2); } At -O0 -g we really should be able to put breakpoint on goto f1 and see the z variable. Another testcase I've been playing with is: void bar (int i) { } void foo (int i, int j) { if (j) { bar (i + 1); goto f1; } bar (i + 2); goto f2; f1: if (i > 10) goto f3; f2: if (i > 40) goto f4; else goto f5; f3: bar (i); f4: bar (i); f5: bar (i); } int main (void) { foo (0, 1); foo (11, 1); foo (21, 0); foo (41, 0); return 0; } Here IMNSHO at -O0 -g one should be able to step through all the gotos, so there should be some instructions with the locations of the gotos. With the attached patch one goto gets a location in the assembly, but the rest don't. One problem is that already the into_cfglayout pass does some optimizations I wouldn't think are appropriate for -O0, like merging basic blocks. That's e.g. where the goto_locus of goto f1; is gone. Either we should prevent that kind of optimization if (!optimize) and the edge has goto_locus, or e.g. could insert a nop insn with goto_locus as INSN_LOCATOR and hope at -O0 nothing later on optimizes that out. Another problem is with the conditional branches. For them I'm afraid we can't put goto_locus on the conditional jump. If just one edge has goto_locus and the other does not, at (!optimize) we could possibly invert the condition and thus let the unconditional jump be the insn that holds the goto_locus INSN_LOCATOR. But for the case where both edges have goto_locus, I think we should just insert an extra conditional jump, so that there are two unconditional jumps, each with its goto_locus. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36690