public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jan Hubicka <hubicka@ucw.cz>
To: Jan Hubicka <hubicka@ucw.cz>,
	Mark Mitchell <mark@codesourcery.com>,
	gcc@gcc.gnu.org
Subject: Re: GCC Status Report (2004-03-21)
Date: Tue, 23 Mar 2004 19:20:00 -0000	[thread overview]
Message-ID: <20040323170318.GD28573@atrey.karlin.mff.cuni.cz> (raw)
In-Reply-To: <20040323161005.GA20329@nevyn.them.org>

> On Mon, Mar 22, 2004 at 12:37:21PM +0100, Jan Hubicka wrote:
> > > 
> > > GCC 3.4
> > > =======
> > > * Jan Hubicka
> > > 
> > >   PR 13974 relates to cases where GCC 3.4 emits bad debugging
> > >   information.  This is an important PR because it's going to affect
> > >   people's ability to use GCC 3.4 for development.  From looking at
> > >   the PR, it looks like you and Dan Jacobowitz have reached some kind
> > >   of consensus, and on 2004-03-14 you indicated you'd have patch
> > >   "Monday or Tuesday".  Is that patch available?  Has Dan looked it
> > >   over and confirmed it fixes the problem?
> > Sorry for being late, somehow the patch got suck in testing scripts and
> > I managed to not attach it to the history.
> > 
> > The patch makes debug information with optimization less accurate, at
> > least in my "gcov" metric right now (I do gcov with and without
> > optimization and diff the output).  I am not sure how to test the
> > patch more throroughly as the problem mentioned in PR is not caught by
> > my testing (the line number is one instruction off that makes no
> > difference for gcov.  The concept is little bit more safe and of course
> > i can go other way around and simply modify all the
> > emit_insn_before/after calls that do not relate to the specified
> > instruction to use different name.
> > 
> > I am not sure how far we want to go for 3.4.  The patch attached just
> > modify the existing functions without attempting to do the
> > classification.
> > 
> > 2004-03-22  Jan Hubicka  <jh@suse.cz>
> > 	* emit_rtl.c (emit_*_insn_before, emit_*_insn_after): Set locators
> > 	according to the specified instruction.
> 
> One comment on the patch itself: we should make a decision about how to
> approach this, one way or the other; this leaves us with both the base
> and _sameloc versions of these functions.

I am just testing version that kills the _sameloc, invents _noloc
versions and updates uses in the cfg code that cause most of noise.  It
is roughly 20Kb patch however. (so newly invented basic blocks and code
inserted into edges don't have random line number infromation attached
to them)
> 
> On Tue, Mar 23, 2004 at 12:52:16AM -0800, Mark Mitchell wrote:
> > Dan (Jacobowitz), what say you about this patch and/or its empirical 
> > behavior in GDB-land?
> 
> It does fix the regression.  The resulting line number information
> makes more logical sense to me, also.  But I would like to understand
> what Jan means by "less accurate"; could you give a testcase so that I
> can examine the output myself, Jan?

What I do is to simply compile GCC with optimization and coverage
testing.

Honza
> 
> We may want to use this patch for now and mark this for further
> investigation in 3.5.
> 
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer

  reply	other threads:[~2004-03-23 17:03 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-22  0:49 Mark Mitchell
2004-03-22  7:56 ` Hans-Peter Nilsson
2004-03-23 17:10   ` Mark Mitchell
2004-03-22 15:27 ` Jan Hubicka
2004-03-23 17:25   ` Mark Mitchell
2004-03-23 19:06     ` Daniel Jacobowitz
2004-03-23 19:20       ` Jan Hubicka [this message]
2004-03-23 19:23         ` Jan Hubicka
2004-03-23 19:24           ` Daniel Jacobowitz
2004-03-23 19:37             ` Jan Hubicka
2004-03-24  5:37           ` Mark Mitchell
2004-03-22  6:03 Billinghurst, David (CALCRTS)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040323170318.GD28573@atrey.karlin.mff.cuni.cz \
    --to=hubicka@ucw.cz \
    --cc=gcc@gcc.gnu.org \
    --cc=mark@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).