From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10144 invoked by alias); 10 Jul 2008 13:44:48 -0000 Received: (qmail 8561 invoked by alias); 10 Jul 2008 13:43:53 -0000 Date: Thu, 10 Jul 2008 13:44:00 -0000 Message-ID: <20080710134353.8559.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: "hubicka at ucw dot cz" 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/msg01018.txt.bz2 ------- Comment #4 from hubicka at ucw dot cz 2008-07-10 13:43 ------- Subject: Re: [4.3/4.4 Regression] .debug_line first line is behind the first instruction > 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 Yes, this is long lasting problem. Basically even at -O0 we can elliminate some of user code completely, while in theory we probably ought to maintain even stuff like empty statements. I am not big friend of idea of making edges sort of "abnormal" ie blocks unmergeable just to preserve debug info. I guess making -O0 to not elliminate NOP instruction and merge block to insert one when last instruction of former block is not having same locator is better way to go given that there are more general problems like this. On tree level we will likely need something similar (ie empty statements holding as placeholders). > 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. Gimplifier already ought to do COND expr jumping to GOTO expr since I run into this problem in gcov output. There is code in cfgcleanup preventing forwarding the edges before gcoving is done. Later we forward across the forwarder block that is probably optimiztion we need to disable at O0 if we worry about this (ie forward across forwarder block only if the forwarders block edge is having no locator or same locator as the edge we are forwarding). Honza > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36690 > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36690