This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug debug/13974] [3.4/3.5 regression] bad line marker in debug info
- From: "jh at suse dot cz" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 14 Mar 2004 17:42:55 -0000
- Subject: [Bug debug/13974] [3.4/3.5 regression] bad line marker in debug info
- References: <20040202092323.13974.mec.gnu@mindspring.com>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From jh at suse dot cz 2004-03-14 17:42 -------
Subject: Re: [3.4/3.5 regression] bad line marker in debug info
>
> ------- Additional Comments From drow at false dot org 2004-03-14 17:31 -------
> Subject: Re: [3.4/3.5 regression] bad line marker in debug info
>
> On Sun, Mar 14, 2004 at 11:12:43AM +0100, Jan Hubicka wrote:
> > 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.
>
> Remember what these locators are used for - as far as I know the only
> correct use is for debug information and debugging dumps. So what do
> we gain from not giving them a location - not very much.
We also use them for coveraging. I did some testing with the idea and
at -O2 it made coverages be more messed up than they are currently (we
invented new disjoint places with same locators while moving the code
not directly attached to the line so we counted lines multiple times),
so at least counting the number of executions of lines did went more
wrong than with current approach.
On the other hand on profiling-branch we do coveraging earlier so we
almost elliminate these effects and both debugging and coverage is
messed up at -O2 on mainline anyway..
>
> > 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.
>
> Well, that's what I'd like to see.
Hmm, OK, I can find time to do it at monday or tuesday if it looks
acceptable for 3.4 too.
Honza
>
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13974
>
> ------- 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=13974