This is the mail archive of the
mailing list for the GCC project.
Re: [Bug debug/13974] [3.4/3.5 regression] bad line marker in debug info
- From: Jan Hubicka <jh at suse dot cz>
- To: Jan Hubicka <jh at suse dot cz>,mmitchel at gcc dot gnu dot org <gcc-bugzilla at gcc dot gnu dot org>,gcc-patches at gcc dot gnu dot org
- Date: Sun, 14 Mar 2004 11:12:43 +0100
- Subject: Re: [Bug debug/13974] [3.4/3.5 regression] bad line marker in debug info
- References: <firstname.lastname@example.org> <email@example.com> <20040313220954.GV6995@kam.mff.cuni.cz> <20040314012930.GA32233@nevyn.them.org>
> On Sat, Mar 13, 2004 at 11:09:54PM +0100, Jan Hubicka wrote:
> > >
> > > ------- Additional Comments From mmitchel at gcc dot gnu dot org 2004-03-11 05:07 -------
> > > Jan, please let me know what is going on with this bug.
> > Hi,
> > I still tend to think in favour of explicitly setting locators for places where
> > we know we are splitting single instruction into multiple ones in some way. It
> > seems to me that in most cases optimizers insert new instructions that are not
> > explicitly attached to statements assigned to surrounding instrucitons.
> > however I am not thrilled about it and the other way around may work well in
> > most cases.
> > The attached patch fix the testcase by similar way as we fixed reload
> > previously. The other way is to make emit_insn_after behave as
> > emit_insn_after_sameloc but I think it is more intrussive. Sorry for taking my
> > time. The patch has failed for misterous reasons and it took me a while to
> > realize that it is the side effect of macro argument being evaulated multiple
> > times, so I also moved everything offline.
> Could you explain what you mean by 'more intrusive'? It'd be a much
> smaller patch, for sure.
It does change the behaviour more than the patch above.
> Personally, I'd rather fix everywhere that emits an instruction, using
> some other instruction before or after in the instruction stream as an
> anchor, that is _not_ associated with that instruction, to specify so
> explicitly. Do you even have an example of this?
Code motion in loop optimizer, gcse, profiling and similar code emitting
to BB headers/footers and such. You are quite right that once you
choose particular instruction in the middle of basic block to emit
something around, you usually want to have it associated with that
instruction in local optimizers.
The questional thing is what to do when instrucitons already have
locators set (ie you are doing code motion and such), but if it really
seems to be sane to just flip the API other way around, I can rename the
emit functions *_noloc and update the uses in CFG, loop and friends.
> Daniel Jacobowitz
> MontaVista Software Debian GNU/Linux Developer