GCC Status Report (2004-03-21)

[Jan Hubicka]

> 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