From: Aldy Hernandez <aldyh@redhat.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>, jason merrill <jason@redhat.com>
Subject: Re: [debug-early] reuse variable DIEs and fix their context
Date: Thu, 28 Aug 2014 17:35:00 -0000 [thread overview]
Message-ID: <53FF6840.9030505@redhat.com> (raw)
In-Reply-To: <CAFiYyc0rftZkObJxo13UCwLvkhqMPNXkE11g-8tvdefQmhN2BQ@mail.gmail.com>
On 08/28/14 06:58, Richard Biener wrote:
> On Wed, Aug 27, 2014 at 4:42 AM, Aldy Hernandez <aldyh@redhat.com> wrote:
>> This patch fixes a bunch of guality failures. With it I get 144 guality.exp
>> failures vs. 163 for "make check-gcc RUNTESTFLAGS=guality.exp". A lot
>> better than 100% fail rate ;-).
>>
>> Variable DIEs were not being reused. Instead, variable DIEs even had the
>> wrong context (unilaterally the compilation unit). The attached patch
>> reuses variable DIEs that have been outputted earlier. It also fixes the
>> context by correcting the context on the second round.
>>
>> I have also added a bit field to the DIE structure to record if a DIE has
>> been generated early.
>>
>> Again, this is all a rough draft, but feel free to comment.
>
> I wonder if we can't not force a proper context die (ISTR dwarf2out.c
> lazily handles some contexts in some circumstances). All parent
Hmmm, I don't see any of this lazy context setting you speak of, but...
> "trees" should be readily available and we should be able to create
> DIEs for them.
I wonder if instead of early dumping of all the DECLs, we could only
dump the toplevel scoped DECLs, and let inheritance set the proper contexts.
We could start with calling dwarf2out_early_decl() for each function
decl, and then for every global. This is analogous to what we currently
do for late dwarf2out.
see final.c for the functions:
if (!DECL_IGNORED_P (current_function_decl))
debug_hooks->function_decl (current_function_decl);
see c/c-decl.c for the globals:
FOR_EACH_VEC_ELT (*all_translation_units, i, t)
c_write_global_declarations_2 (BLOCK_VARS (DECL_INITIAL (t)));
c_write_global_declarations_2 (BLOCK_VARS (ext_block));
The problem being that to calculate `ext_block' above, we need intimate
knowledge of scopes and such, only available in the FE. Is there a
generic way of determining if a DECL is in global scope? If, so we
could do:
foreach decl in fld.decls
if (is_global_scope(decl))
dwarf2out_decl (decl)
...and contexts will magically be set.
Is there such a way, or am I going about this the wrong way?
Aldy
next prev parent reply other threads:[~2014-08-28 17:35 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-27 2:43 Aldy Hernandez
2014-08-28 13:58 ` Richard Biener
2014-08-28 17:35 ` Aldy Hernandez [this message]
2014-08-28 18:01 ` Jason Merrill
2014-08-28 19:13 ` Richard Biener
2014-08-28 20:14 ` Jason Merrill
2014-08-29 9:09 ` Richard Biener
2014-09-03 17:55 ` Aldy Hernandez
2014-09-04 10:42 ` Richard Biener
2014-09-05 2:38 ` Aldy Hernandez
2014-09-05 9:00 ` Richard Biener
2014-09-09 0:01 ` Aldy Hernandez
2014-09-09 9:16 ` Richard Biener
2014-09-12 0:51 ` Aldy Hernandez
2014-09-12 8:13 ` Richard Biener
2014-09-12 15:15 ` Jason Merrill
2014-09-12 17:11 ` Aldy Hernandez
2014-09-12 17:33 ` Jason Merrill
2014-09-12 17:48 ` Aldy Hernandez
2014-09-12 17:56 ` Jason Merrill
2014-09-16 15:49 ` Aldy Hernandez
2014-09-15 9:32 ` Richard Biener
2014-09-15 18:46 ` Jason Merrill
2014-12-18 19:26 ` Aldy Hernandez
2014-12-19 11:20 ` Richard Biener
2014-12-19 18:58 ` Jan Hubicka
2014-12-19 19:01 ` Jan Hubicka
2014-12-19 19:02 ` Aldy Hernandez
2014-12-19 19:31 ` Jason Merrill
2014-12-19 19:50 ` Jan Hubicka
2014-12-20 10:09 ` Aldy Hernandez
2015-01-08 12:24 ` Richard Biener
2014-12-19 19:03 ` Aldy Hernandez
2014-09-04 17:53 ` H.J. Lu
2014-09-04 17:54 ` Aldy Hernandez
2014-09-04 18:23 ` Richard Biener
2014-09-04 18:35 ` Aldy Hernandez
2014-09-04 18:38 ` Christophe Lyon
2014-09-04 19:42 ` Jan-Benedict Glaw
2015-01-08 15:20 Aldy Hernandez
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=53FF6840.9030505@redhat.com \
--to=aldyh@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jason@redhat.com \
--cc=richard.guenther@gmail.com \
/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).