From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20404 invoked by alias); 23 Mar 2004 17:31:36 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 20371 invoked from network); 23 Mar 2004 17:31:34 -0000 Received: from unknown (HELO atrey.karlin.mff.cuni.cz) (195.113.31.123) by sources.redhat.com with SMTP; 23 Mar 2004 17:31:34 -0000 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 4018) id 5FB954C038A; Tue, 23 Mar 2004 18:31:34 +0100 (CET) Date: Tue, 23 Mar 2004 19:37:00 -0000 From: Jan Hubicka To: Jan Hubicka , Mark Mitchell , gcc@gcc.gnu.org Subject: Re: GCC Status Report (2004-03-21) Message-ID: <20040323173134.GF28573@atrey.karlin.mff.cuni.cz> References: <200403212027.i2LKRSjQ019842@sirius.codesourcery.com> <20040322113721.GC28573@atrey.karlin.mff.cuni.cz> <405FFAC0.4020803@codesourcery.com> <200403212027.i2LKRSjQ019842@sirius.codesourcery.com> <20040322113721.GC28573@atrey.karlin.mff.cuni.cz> <20040323161005.GA20329@nevyn.them.org> <20040323170318.GD28573@atrey.karlin.mff.cuni.cz> <20040323171042.GE28573@atrey.karlin.mff.cuni.cz> <20040323172501.GA23157@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040323172501.GA23157@nevyn.them.org> User-Agent: Mutt/1.5.4i X-SW-Source: 2004-03/txt/msg01345.txt.bz2 > On Tue, Mar 23, 2004 at 06:10:42PM +0100, Jan Hubicka wrote: > > Hi, > > here is the updated patch. It bootstraped i686-pc-gnu-linux and I am > > running full testing on mainline and branch i686/ppc now. > > It fixes the problems with wrong gcov counts caused by BB manipulation > > and hope it will be acceptable for Daniel too. I worry relatively > > little about what direction the defaults are, obviously we need to > > revisit most of the emit* calls anyway. > > > > Honza > > > > 2004-03-23 Jan Hubicka > > * cfgrtl.c (try_redirect_by_replacing_jump, > > force_nonfallthru_and_redirect, commit_one_edge_insertion, > > cfg_layout_merge_blocks): Do not attach any line number information > > to newly inserted instructions. > > * emit-rtl.c (emit_insn*_before, emit_insn*_after): Rename to > > emit_insn_*_noloc. > > (emit_*insn_before, emit_insn*_after): New. > > (emit_*insn_before_setloc, emit_*insn_after_setloc): Do not overwrite > > existing locators. > > * rtl.h (emit_*insn_before_noloc, emit_*insn_after_noloc): Declare. > > (emit_*insn_before_sameloc, emit_*insn_after_sameloc): Kill. > > Works for me. I had an interesting discussion a couple of days ago > about actually expressing "no line number" in the dwarf output; it's > not clear what the debugger can do with this information, but there are > some possibilities. The main motivation for having instructions with no line number is to avoid false line number markers in dwarf2 output after those instructions (doing something unrelated) has been moved across the instruction stream to strange location. This shows up nicely in gcov output as the line numbers then get artifically high count (and GDB would stop program unnecesarily often if the breakpoint were put to such a line) I am not sure if gdb can do something usefull with knowing that this instruction does not belong to any statement but has been constructed artifically by itself. With current strategy we simply bundle the instruction with the preceeding line that won't make breakpoints to be missplaced and thus everything should work relatively well. Honza > > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer