public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "hubicka at ucw dot cz" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/17924] [4.0 Regression] gcc.dg/debug/dwarf2/dwarf-die7.c fails Date: Thu, 02 Dec 2004 16:06:00 -0000 [thread overview] Message-ID: <20041202160546.28484.qmail@sourceware.org> (raw) In-Reply-To: <20041010202301.17924.pinskia@gcc.gnu.org> ------- Additional Comments From hubicka at ucw dot cz 2004-12-02 16:05 ------- Subject: Re: [4.0 Regression] gcc.dg/debug/dwarf2/dwarf-die7.c fails > > ------- Additional Comments From bje at gcc dot gnu dot org 2004-12-02 05:43 ------- > Trivial test case: > > static int f () { return 3; } > int main() { return f (); } > > Here, cgraph_optimize() decides to inline f() into main() and then eliminates > the node for f() from the call graph. cgraph_expand_function() never emits > assembly for f(), so no DIE is emitted either. The cgraph dump file summarises > the situation: > > Optimized callgraph: > > main/1: 13 insns (5 after inlining) needed tree inlinable > called by: > calls: f/0 (inlined) > f/0: (inline copy in main/1) 2 insns reachable tree local inlinable > called by: main/1 (inlined) > calls: > > Final callgraph: > > main/1: 13 insns (5 after inlining) needed inlinable asm_written > called by: > calls: > > The dilemma here is that we really don't want to emit the real f(), since it is > never called in the translation unit and we don't want to waste text doing so. > All we want is debugging information for f(). I thing the scheme this was supposed to work was to keep the BLOCK node from the inlined version of f() in the DECL_INITIAL of main() so the debug info dumper notice that function f() has been inlined and produce the abstract insteance of it himself. Since the BLOCK nodes are gone and we now attach debug info into statements and we apparently succeeds to remove body of f() entirely even without optimization we no longer do this. I am not sure how to deal with this properly either (I am not debug info expert). The crude version of patch is not correct as the main point is to be able to breakpoint inside f() and get program stopped correctly that apparently won't work as everything about f() in main() is dead. We even might declare this proper behaviour and simply make the function nonempty in the testcase or we might add dummy empty statements and maintain it around till end of compilation but that sounds involved for such a minnor nit in dedbug info. Honza > > The following crude patch makes things work, but it's wrong: > > Index: cgraphunit.c > =================================================================== > RCS file: /home/bje/gcc-cvs/gcc/gcc/cgraphunit.c,v > retrieving revision 1.90 > diff -u -p -r1.90 cgraphunit.c > --- cgraphunit.c 18 Nov 2004 00:18:43 -0000 1.90 > +++ cgraphunit.c 2 Dec 2004 05:41:16 -0000 > @@ -786,6 +786,14 @@ cgraph_mark_functions_to_output (void) > && !TREE_ASM_WRITTEN (decl) > && !DECL_EXTERNAL (decl)) > node->output = 1; > + else if (DECL_SAVED_TREE (decl) > + && node->global.inlined_to > + && !node->needed > + && node->reachable > + && node->local.local > + && !TREE_ASM_WRITTEN (decl) > + && !DECL_EXTERNAL (decl)) > + node->output = 1; > else > { > /* We should've reclaimed all functions that are not needed. */ > @@ -811,9 +819,6 @@ static void > cgraph_expand_function (struct cgraph_node *node) > { > tree decl = node->decl; > - > - /* We ought to not compile any inline clones. */ > - gcc_assert (!node->global.inlined_to); > > if (flag_unit_at_a_time) > announce_function (decl); > > Any ideas on how to proceed? > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17924 > > ------- 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=17924
next prev parent reply other threads:[~2004-12-02 16:06 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2004-10-10 20:23 [Bug debug/17924] New: " pinskia at gcc dot gnu dot org 2004-10-10 20:23 ` [Bug debug/17924] " pinskia at gcc dot gnu dot org 2004-10-11 2:05 ` pinskia at gcc dot gnu dot org 2004-10-15 5:00 ` bje at gcc dot gnu dot org 2004-10-15 6:07 ` bje at gcc dot gnu dot org 2004-10-15 6:43 ` bje at gcc dot gnu dot org 2004-12-02 5:43 ` bje at gcc dot gnu dot org 2004-12-02 16:06 ` hubicka at ucw dot cz [this message] 2004-12-03 1:17 ` dberlin at gcc dot gnu dot org 2004-12-29 20:54 ` pinskia at gcc dot gnu dot org 2004-12-31 22:26 ` dberlin at gcc dot gnu dot org 2004-12-31 22:46 ` dberlin at gcc dot gnu dot org 2005-01-01 3:17 ` dberlin at gcc dot gnu dot org 2005-01-01 12:16 ` jason at redhat dot com 2005-01-04 1:54 ` cvs-commit at gcc dot gnu dot org 2005-01-04 3:10 ` dberlin at gcc dot gnu dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20041202160546.28484.qmail@sourceware.org \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).