GCC Bugzilla – Bug 29609
[4.2/4.3/4.4 Regression] Even with -O0 -g gcc optimizes a goto away and I cannot debug
Last modified: 2008-11-21 23:48:32 UTC
[forwarded from http://bugs.debian.org/395057] In the following sample code, gcc does not create enough debugging information to let gdb break in lines 27, 30, 33, 36. This makes debugging the main() function extremely painful. This is a regression from gcc 2.95 and gcc 3.3, both of which let gdb set a breakpoint on those lines. The ability to debug such code is very important to me, since I usually write my C functions with some cleanup code after a 'failure' label in the style below. [comment from Daniel Jacobowitz: Yes, this was a GDB bug earlier in the day. He's right. I think it's jump threading, or something like that, running even at -O0; seems like it shouldn't, for this reason.] int f1(void) /* this "succeeds", i.e. returns 1 */ { return 1; } int f2(void) /* this "succeeds", i.e. returns 1 */ { return 1; } int f3(void) /* this "fails", i.e. returns 0 */ { return 0; } int f4(void) /* this "succeeds", i.e. returns 1 */ { return 1; } int main(int argc, char *argv[]) { int c; if (!f1()) goto failure; if (!f2()) goto failure; if (!f3()) goto failure; if (!f4()) goto failure; success: return 0; failure: return 1; }
[t.c : 26] if ([t.c : 26] D.1570 == 0) [t.c : 27] goto failure; else goto <L0>; This looks like an expand issue ... Or a lower gimple issue.
A regression hunt on powerpc-linux looking for DWARF2 line number information for lines with gotos identified this patch: http://gcc.gnu.org/viewcvs?view=rev&rev=83385 r83385 | hubicka | 2004-06-19 15:33:06 +0000 (Sat, 19 Jun 2004)
There are at least 2 issues here: 1) We just lose the locus of the goto statements when we lower GIMPLE and when we jump across forwarded blocks. 2) When we don't lose the locus in GIMPLE, we lose it in cfgexpand. I'm working on a fix for both issues.
There doesn't seem to be another way to get this to work, than the proposed way with extra basic blocks. The things I've tried either break gcc, or gdb, or debug info. Unassigning.
xf. http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01789.html I was wrong to object to this patch -- there really doesn't seem to be any other way. It's funny, on the one hand we complain about the code quality of -O0, but on the other we have to do quite silly things such as adding jumps to jumps to keep rather important debug information around... Olivier, any chance someone at AdaCore can pick this up and re-submit it to gcc-patches?
Subject: Re: [4.1/4.2/4.3 Regression] Even with -O0 -g gcc optimizes a goto away and I cannot debug Hi Steven, steven at gcc dot gnu dot org wrote: > xf. http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01789.html > > I was wrong to object to this patch No problem, and many thanks for getting back to us on this issue. What really matters is feedback/discussion IMO, and your comments had us look for better ways to perform the task. This is a positive outcome even if we haven't (yet) pushed further for an inclusion into the FSF tree. > there really doesn't seem to be any other way. It's funny, on the > one hand we complain about the code quality of -O0, but on the other > we have to do quite silly things such as adding jumps to jumps to > keep rather important debug information around... Right. We have several constraints at play (want to debug, want the ability to debug (-g) not to modify the generated code, and want to limit generated code bloats), and it's not always possible to progress on one aspect without effects on the others. I like the recently suggested "-Og" idea because it offers a way through. > Olivier, any chance someone at AdaCore can pick this up and re-submit it to > gcc-patches? We can definitely resubmit the current version we have (I copied the author). Thanks again for your feedback, Olivier
Subject: Re: [4.1/4.2/4.3 Regression] Even with -O0 -g gcc optimizes a goto away and I cannot debug Olivier Hainque wrote: > We can definitely resubmit the current version we have (I copied the > author). Thanks again for your feedback, Actually, there was another related submission at http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00099.html There was an interesting exchange with Richard Guenther there, which didn't quite reach a conclusion at the time.
Closing 4.1 branch.
Subject: Bug 29609 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
Fixed.