public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/94273] [10 Regression] ICE in splice_child_die, at dwarf2out.c:5657 since r10-7235-g52b3aa8be1893848
Date: Fri, 27 Mar 2020 08:37:15 +0000	[thread overview]
Message-ID: <bug-94273-4-pBgPb2oXfY@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-94273-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94273

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
OK, so during early creation of the DIE for the type we end up in

static void
gen_struct_or_union_type_die (tree type, dw_die_ref context_die,
                                enum debug_info_usage usage)
{
...
  int complete = (TYPE_SIZE (type)
                  && (! TYPE_STUB_DECL (type)
                      || ! TYPE_DECL_SUPPRESS_DEBUG (TYPE_STUB_DECL (type))));

where complete is false because of TYPE_DECL_SUPPRESS_DEBUG.  When record
the type to be re-processed later and between now and then the C++ FE does
note_debug_info_needed via maybe_emit_vtables and clears
TYPE_DECL_SUPPRESS_DEBUG, causing the type to be completed during 
retry_incomplete_types processing.

I think PR93951 may be related in the end because the conditions on when
exactly we emit what parts of debug info is quite intricate in dwarf2out.

Now, for this bug I guess we should choose to piggy-back on that,
making should_emit_struct_debug return false for DINFO_LEVEL_TERSE
or initializing debug_struct_{generic,ordinary} accordingly.

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index b1fa6f5ff7c..378a27394e8 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -399,6 +399,9 @@ get_full_len (const wide_int &op)
 static bool
 should_emit_struct_debug (tree type, enum debug_info_usage usage)
 {
+  if (debug_info_level <= DINFO_LEVEL_TERSE)
+    return false;
+
   enum debug_struct_file criterion;
   tree type_decl;
   bool generic = lang_hooks.types.generic_p (type);

thoughts?

The DWARF we generate for the testcase at -g1 is then

 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <c>   DW_AT_producer    : (indirect string, offset: 0x0): GNU C++14 10.0.1
2
0200325 (experimental) -mtune=generic -march=x86-64 -g1
    <10>   DW_AT_language    : 4        (C++)
    <11>   DW_AT_name        : (indirect string, offset: 0x4a): t.ii
    <15>   DW_AT_comp_dir    : (indirect string, offset: 0x4f):
/home/rguenther/
obj/gcc
    <19>   DW_AT_ranges      : 0x0
    <1d>   DW_AT_low_pc      : 0x0
    <25>   DW_AT_stmt_list   : 0x0
 <1><29>: Abbrev Number: 2 (DW_TAG_variable)
    <2a>   DW_AT_name        : b
    <2c>   DW_AT_decl_file   : 1
    <2d>   DW_AT_decl_line   : 3
    <2e>   DW_AT_decl_column : 12
    <2f>   DW_AT_external    : 1
    <2f>   DW_AT_declaration : 1
 <1><2f>: Abbrev Number: 3 (DW_TAG_variable)
    <30>   DW_AT_specification: <0x29>
    <34>   DW_AT_decl_line   : 4
    <35>   DW_AT_decl_column : 5
    <36>   DW_AT_location    : 9 byte block: 3 0 0 0 0 0 0 0 0  (DW_OP_addr: 0)
 <1><40>: Abbrev Number: 4 (DW_TAG_subprogram)
    <41>   DW_AT_external    : 1
    <41>   DW_AT_name        : c
    <43>   DW_AT_decl_file   : 1
    <44>   DW_AT_decl_line   : 2
    <45>   DW_AT_decl_column : 16
    <46>   DW_AT_linkage_name: (indirect string, offset: 0x67): _ZN1a1cEv
    <4a>   DW_AT_virtuality  : 1        (virtual)
    <4b>   DW_AT_vtable_elem_location: 2 byte block: 10 0       (DW_OP_constu:
0)
    <4e>   DW_AT_accessibility: 3       (private)
    <4f>   DW_AT_low_pc      : 0x0
    <57>   DW_AT_high_pc     : 0xb
    <5f>   DW_AT_frame_base  : 1 byte block: 9c         (DW_OP_call_frame_cfa)
    <61>   DW_AT_GNU_all_call_sites: 1
 <1><61>: Abbrev Number: 0

  parent reply	other threads:[~2020-03-27  8:37 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-23 11:20 [Bug c++/94273] New: ice in splice_child_die, at dwarf2out.c:5657 dcb314 at hotmail dot com
2020-03-23 11:28 ` [Bug c++/94273] " dcb314 at hotmail dot com
2020-03-23 11:41 ` dcb314 at hotmail dot com
2020-03-23 12:55 ` [Bug debug/94273] [10 Regression] ICE in splice_child_die, at dwarf2out.c:5657 since r10-7235-g52b3aa8be1893848 marxin at gcc dot gnu.org
2020-03-23 12:55 ` marxin at gcc dot gnu.org
2020-03-23 14:08 ` rguenth at gcc dot gnu.org
2020-03-23 19:53 ` stilor at att dot net
2020-03-26 13:12 ` jakub at gcc dot gnu.org
2020-03-26 13:21 ` rguenth at gcc dot gnu.org
2020-03-26 19:01 ` stilor at att dot net
2020-03-26 23:39 ` stilor at att dot net
2020-03-27  8:37 ` rguenth at gcc dot gnu.org [this message]
2020-03-27  8:46 ` rguenth at gcc dot gnu.org
2020-03-27 13:01 ` cvs-commit at gcc dot gnu.org
2020-03-27 13:01 ` rguenth at gcc dot gnu.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=bug-94273-4-pBgPb2oXfY@http.gcc.gnu.org/bugzilla/ \
    --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).