[Bug debug/36690] [4.3/4.4 Regression] .debug_line first line is behind the first instruction

["hubicka at ucw dot cz" <gcc-bugzilla at gcc dot gnu dot org>]

------- 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