[Bug debug/36690] [4.3/4.4 Regression] .debug_line first line is behind the first instruction
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.3.3 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36690
[Bug debug/36690] [4.3/4.4 Regression] .debug_line first line is behind the first instruction
--- Comment #8 from cnstar9988 at gmail dot com 2008-10-10 07:28 --- Target Milestone 4.3.3? But this patch didn't committed to 4.3 branch. why closed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36690
[Bug debug/36690] [4.3/4.4 Regression] .debug_line first line is behind the first instruction
--- Comment #7 from jakub at gcc dot gnu dot org 2008-10-07 19:00 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36690
[Bug debug/36690] [4.3/4.4 Regression] .debug_line first line is behind the first instruction
--- Comment #6 from jakub at gcc dot gnu dot org 2008-10-07 18:50 --- Subject: Bug 36690 Author: jakub Date: Tue Oct 7 18:48:40 2008 New Revision: 140948 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140948 Log: PR debug/29609 PR debug/36690 PR debug/37616 * basic-block.h (struct edge_def): Add goto_block field. * cfglayout.c (fixup_reorder_chain): Ensure that there is at least one insn with locus corresponding to edge's goto_locus if !optimize. * profile.c (branch_prob): Copy edge's goto_block. * cfgrtl.c (force_nonfallthru_and_redirect): Use goto_locus for emitted jumps. (cfg_layout_merge_blocks): Emit a nop with edge's goto_locus locator in between the merged basic blocks if !optimize and needed. * cfgexpand.c (expand_gimple_cond): Convert goto_block and goto_locus into RTL locator. For unconditional jump use that locator for the jump insn. (expand_gimple_cond): Convert goto_block and goto_locus into RTL locator for all remaining edges. For unconditional jump use that locator for the jump insn. * cfgcleanup.c (try_forward_edges): Avoid the optimization if there is more than one edge or insn locator along the forwarding edges and !optimize. If there is just one, set e->goto_locus. * tree-cfg.c (make_cond_expr_edges, make_goto_expr_edges): Set also edge's goto_block. (move_block_to_fn): Adjust edge's goto_block. * gcc.dg/debug/pr29609-1.c: New test. * gcc.dg/debug/pr29609-2.c: New test. * gcc.dg/debug/pr36690-1.c: New test. * gcc.dg/debug/pr36690-2.c: New test. * gcc.dg/debug/pr36690-3.c: New test. * gcc.dg/debug/pr37616.c: New test. * gcc.dg/debug/dwarf2/pr29609-1.c: New test. * gcc.dg/debug/dwarf2/pr29609-2.c: New test. * gcc.dg/debug/dwarf2/pr36690-1.c: New test. * gcc.dg/debug/dwarf2/pr36690-2.c: New test. * gcc.dg/debug/dwarf2/pr36690-3.c: New test. * gcc.dg/debug/dwarf2/pr37616.c: New test. Added: trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr29609-1.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr29609-2.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr36690-1.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr36690-2.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr36690-3.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr37616.c trunk/gcc/testsuite/gcc.dg/debug/pr29609-1.c trunk/gcc/testsuite/gcc.dg/debug/pr29609-2.c trunk/gcc/testsuite/gcc.dg/debug/pr36690-1.c trunk/gcc/testsuite/gcc.dg/debug/pr36690-2.c trunk/gcc/testsuite/gcc.dg/debug/pr36690-3.c trunk/gcc/testsuite/gcc.dg/debug/pr37616.c Modified: trunk/gcc/ChangeLog trunk/gcc/basic-block.h trunk/gcc/cfgcleanup.c trunk/gcc/cfgexpand.c trunk/gcc/cfglayout.c trunk/gcc/cfgrtl.c trunk/gcc/profile.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36690
[Bug debug/36690] [4.3/4.4 Regression] .debug_line first line is behind the first instruction
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||10/msg00017.html Status|NEW |ASSIGNED Last reconfirmed|2008-07-01 15:52:34 |2008-10-03 08:55:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36690
[Bug debug/36690] [4.3/4.4 Regression] .debug_line first line is behind the first instruction
--- Comment #5 from jsm28 at gcc dot gnu dot org 2008-08-27 22:04 --- 4.3.2 is released, changing milestones to 4.3.3. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.3.2 |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36690
[Bug debug/36690] [4.3/4.4 Regression] .debug_line first line is behind the first instruction
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36690
[Bug debug/36690] [4.3/4.4 Regression] .debug_line first line is behind the first instruction
--- 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
[Bug debug/36690] [4.3/4.4 Regression] .debug_line first line is behind the first instruction
--- Comment #3 from jakub at gcc dot gnu dot org 2008-07-10 12:01 ---
Created an attachment (id=15888)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15888&action=view)
gcc44-pr36690.patch
Unfinished patch which solves the testcase in this PR and a couple of other
problems, but still there are plenty of issues.
It adds goto_block field to edges, because sometimes an edge is the only place
that uses certain scope. Consider say:
void bar (int);
void foo (int i)
{
if (!i)
bar (0);
else
{
static int z = 5;
goto f1;
}
bar (1);
f1:
bar (2);
}
At -O0 -g we really should be able to put breakpoint on goto f1 and see the z
variable. Another testcase I've been playing with is:
void
bar (int i)
{
}
void
foo (int i, int j)
{
if (j)
{
bar (i + 1);
goto f1;
}
bar (i + 2);
goto f2;
f1:
if (i > 10)
goto f3;
f2:
if (i > 40)
goto f4;
else
goto f5;
f3:
bar (i);
f4:
bar (i);
f5:
bar (i);
}
int
main (void)
{
foo (0, 1);
foo (11, 1);
foo (21, 0);
foo (41, 0);
return 0;
}
Here IMNSHO at -O0 -g one should be able to step through all the gotos, so
there should be some instructions with the locations of the gotos. With the
attached patch one goto gets a location in the assembly, but the rest don't.
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
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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36690
[Bug debug/36690] [4.3/4.4 Regression] .debug_line first line is behind the first instruction
--- Comment #2 from jakub at gcc dot gnu dot org 2008-07-02 09:22 ---
This is caused by the implicit gotos at the end of basic blocks.
See http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01840.html
During cfgexpand this can be IMHO fixed by setting curr_location before
emitting the jump, not after it (otherwise e->goto_locus is IMHO useless,
as most likely the following statements will change curr_location before
anything is emitted):
--- gcc/cfgexpand.c.jj 2008-06-06 09:17:07.0 +0200
+++ gcc/cfgexpand.c 2008-07-02 10:43:54.0 +0200
@@ -1610,9 +1610,9 @@ expand_gimple_basic_block (basic_block b
if (e && e->dest != bb->next_bb)
{
- emit_jump (label_rtx_for_bb (e->dest));
if (e->goto_locus)
set_curr_insn_source_location (e->goto_locus);
+ emit_jump (label_rtx_for_bb (e->dest));
e->flags &= ~EDGE_FALLTHRU;
}
Not sure if expand_gimple_cond_expr should stay as is or be modified as well.
This fixes this problem for the few early RTL passes, but then we go into
cfglayout mode and the JUMP is removed again.
force_nonfallthru_and_redirect then when going out of cfglayout mode recreates
the JUMP again, but completely ignores e->goto_locus:
if (target == EXIT_BLOCK_PTR)
{
#ifdef HAVE_return
emit_jump_insn_after_noloc (gen_return (), BB_END (jump_block));
#else
gcc_unreachable ();
#endif
}
else
{
rtx label = block_label (target);
emit_jump_insn_after_noloc (gen_jump (label), BB_END (jump_block));
JUMP_LABEL (BB_END (jump_block)) = label;
LABEL_NUSES (label)++;
}
One problem is that we have just locus for the edges, not BLOCK, so if
force_nonfallthru_and_redirect were to call emit_jump_insn_after_setloc
instead,
the question is what BLOCK should be used for it (e.g. pick the block from insn
before the jump (if any)? What to do if there is none in the basic block?).
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||rakdver at gcc dot gnu dot
||org, hubicka at gcc dot gnu
||dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36690
[Bug debug/36690] [4.3/4.4 Regression] .debug_line first line is behind the first instruction
--- Comment #1 from jsm28 at gcc dot gnu dot org 2008-07-01 15:52 --- I've also observed this problem (as causing a number of GDB testsuite failures). With both 4.2 and 4.3, the function prologue is followed by a jump, the loop body, and then the test of the loop condition which the jump jumps to. The loop body has the correct line number, as does the condition. With 4.2, the jump has the same line number as the condition, so that's the line number to which GDB assigns a breakpoint on the function. With 4.3, the jump insn does not have a line number and GDB decides to use the line number of the loop body, and the GDB tests fail. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-01 15:52:34 date|| Summary|.debug_line first line is |[4.3/4.4 Regression] |behind the first instruction|.debug_line first line is ||behind the first instruction Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36690
