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


  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: link
Be 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).