[Bug debug/41063] New: ICE in output_die
Compile the following with -g for a DWARF target:
$ cat test.cc
struct A {
virtual void run();
};
void test() {
struct B : public A {
void run() {
struct C : public A {
C() { }
B *b_;
};
C c;
}
};
B b;
}
$ gcc -v
Reading specs from /home/ccoutant/opensource/gcc-trunk/build-native/gcc/specs
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++ --disable-bootstrap
: (reconfigured) ../gcc/configure --disable-bootstrap --enable-languages=c,c++
--no-create --no-recursion
Thread model: posix
gcc version 4.5.0 20090727 (experimental) (GCC)
$ gcc -g -c test.cc
test.cc:16:1: internal compiler error: in output_die, at dwarf2out.c:8845
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
By the time we get to dwarf2out_finish(), the DIE graph has a cycle in it:
struct B -> subprogram run -> struct C -> struct B -> ...
It seems to have put the DIE for struct B as a child of struct C instead of the
DIE for "pointer to B".
Because of the cycle, none of the DIEs involved are placed in the main compunit
tree. The DIE for the type "pointer to B" (which did make it into the main
tree) tries to reference the DIE for the type B, which is part of the cycle,
and triggers the assertion.
When the vtable for struct C is output from note_debug_info_needed(), a DIE for
struct B has not been built yet. When gen_type_die_with_usage() sees the
pointer to B, it then calls itself recursively to generate the DIE for B, but
it passes the same context that it was given, which is the lexical block inside
B::run(), and struct B is then created as a child of that lexical block, thus
forming the cycle.
--
Summary: ICE in output_die
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ccoutant at gcc dot gnu dot org
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41063
[Bug debug/41063] ICE in output_die
--- Comment #1 from ccoutant at gcc dot gnu dot org 2009-08-13 23:40 --- Created an attachment (id=18361) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18361&action=view) Proposed patch to dwarf2out.c * dwarf2out.c (gen_type_die_with_usage): Set context_die for basis type of reference or pointer type. -- ccoutant at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ccoutant at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41063
[Bug debug/41063] ICE in output_die
--- Comment #2 from ccoutant at gcc dot gnu dot org 2009-08-28 20:32 --- Subject: Bug 41063 Author: ccoutant Date: Fri Aug 28 20:32:29 2009 New Revision: 151185 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151185 Log: gcc/ChangeLog: PR debug/41063 * dwarf2out.c (gen_type_die_with_usage): Use proper context for struct/union/enum types local to a function. gcc/testsuite/ChangeLog: PR debug/41063 * g++.dg/debug/dwarf2/pr41063.C: New test. Added: trunk/gcc/testsuite/g++.dg/debug/dwarf2/pr41063.C Modified: trunk/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41063
[Bug debug/41063] ICE in output_die
--- Comment #3 from ccoutant at gcc dot gnu dot org 2009-08-28 20:35 --- Subject: Bug 41063 Author: ccoutant Date: Fri Aug 28 20:35:16 2009 New Revision: 151187 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151187 Log: gcc/ChangeLog: PR debug/41063 * dwarf2out.c (gen_type_die_with_usage): Use proper context for struct/union/enum types local to a function. gcc/testsuite/ChangeLog: PR debug/41063 * g++.dg/debug/dwarf2/pr41063.C: New test. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41063
[Bug debug/41063] ICE in output_die
--- Comment #4 from ccoutant at gcc dot gnu dot org 2009-08-28 23:17 --- Fixed at rev 151187. -- ccoutant at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41063
[Bug testsuite/41700] g++.dg/debug/dwarf2/icf.C
--- Comment #3 from ccoutant at gcc dot gnu dot org 2009-10-17 00:30 --- The insn UID is changed when the call_insn is split, so the vtable slot index can't be found when it's time to build the vcall table. -- ccoutant at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ccoutant at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-10-14 21:03:06 |2009-10-17 00:30:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41700
[Bug testsuite/41700] g++.dg/debug/dwarf2/icf.C
--- Comment #5 from ccoutant at gcc dot gnu dot org 2009-10-23 01:44 --- Created an attachment (id=18876) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18876&action=view) Proposed fix for PR 41700. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41700
[Bug debug/41700] g++.dg/debug/dwarf2/icf.C
--- Comment #6 from ccoutant at gcc dot gnu dot org 2009-10-23 01:46 --- I'm inclined to classify this as a debug problem rather than middle-end. Does that seem reasonable? Steve, could you see if this patch fixes the failure on PA and Itanium? -cary -- ccoutant at gcc dot gnu dot org changed: What|Removed |Added Component|testsuite |debug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41700
[Bug debug/41700] g++.dg/debug/dwarf2/icf.C
--- Comment #9 from ccoutant at gcc dot gnu dot org 2009-10-29 18:13 --- Subject: Bug 41700 Author: ccoutant Date: Thu Oct 29 18:13:27 2009 New Revision: 153719 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153719 Log: gcc/ChangeLog: PR debug/41700 * dwarf2out.c (dwarf2_debug_hooks): Add entries for new hook (two locations in the source). (store_vcall_insn): New function. (lookup_vcall_insn): New function. (dwarf2out_virtual_call_token): Use store_vcall_insn. (dwarf2out_copy_call_info): New function. (dwarf2out_virtual_call): Use lookup_vcall_insn. * emit-rtl.c (try_split): Call copy_call_info debug hook. * debug.h (struct gcc_debug_hooks): Add copy_call_info hook. * debug.c (do_nothing_debug_hooks): Add dummy entry for new hook. (debug_nothing_rtx_rtx): New dummy hook. * dbxout.c (dbx_debug_hooks): Add dummy entry for new hook. (xcoff_debug_hooks): Likewise. * sdbout.c (sdb_debug_hooks): Likewise. * vmsdbgout.c (vmsdbg_debug_hooks): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/dbxout.c trunk/gcc/debug.c trunk/gcc/debug.h trunk/gcc/dwarf2out.c trunk/gcc/emit-rtl.c trunk/gcc/sdbout.c trunk/gcc/vmsdbgout.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41700
[Bug lto/42757] lto1 does not emit common symbols with -fuse-linker-plugin
-- ccoutant at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ccoutant at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-01-15 13:37:53 |2010-03-31 23:30:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42757
[Bug lto/42757] lto1 does not emit common symbols with -fuse-linker-plugin
--- Comment #10 from ccoutant at gcc dot gnu dot org 2010-03-31 23:40 --- Created an attachment (id=20267) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20267&action=view) Gold patch to fix common symbol handling This gold patch ought to fix the problem. Please verify and I'll send it upstream to binutils. * plugin.cc (Pluginobj::get_symbol_resolution_info): Check for prevailing definitions of common symbols. * testsuite/plugin_test_6.sh: New testcase. * testsuite/plugin_common_test_1.c: New testcase. * testsuite/plugin_common_test_2.c: New testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42757
[Bug lto/42757] lto1 does not emit common symbols with -fuse-linker-plugin
--- Comment #11 from ccoutant at gcc dot gnu dot org 2010-04-01 06:32 --- Created an attachment (id=20269) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20269&action=view) Updated gold patch to fix common symbol handling Sorry, I forgot to include the updated testsuite/Makefile.* in the patch... * plugin.cc (Pluginobj::get_symbol_resolution_info): Check for prevailing definitions of common symbols. * testsuite/plugin_test_6.sh: New test case. * testsuite/plugin_common_test_1.c: New test case. * testsuite/plugin_common_test_2.c: New test case. * testsuite/Makefile.am (plugin_test_6): New test case. * testsuite/Makefile.in: Regenerate. -- ccoutant at gcc dot gnu dot org changed: What|Removed |Added Attachment #20267|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42757
[Bug lto/42757] lto1 does not emit common symbols with -fuse-linker-plugin
--- Comment #13 from ccoutant at gcc dot gnu dot org 2010-04-06 22:00 --- gold patch committed -- ccoutant at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42757
[Bug debug/42454] New: debug_ranges table contains empty range for unused .text section with -ffunction-sections
When -ffunction-sections is turned on with -g2, gcc emits an entry into the
.debug_ranges section for the DW_TAG_compile_unit for the range (.Ltext,
.Letext) unconditionally. With -ffunction-sections, the .text section remains
unused, and this entry in .debug_ranges refers to a zero-length range.
That's not normally a problem, but when --gc-sections is turned on in the
linker, the empty .text section can be removed, and the relocations for that
range apply zeroes to that entry, and it now looks like the end of the range
list. Because that's actually the first range entry that gcc emits for the
compile unit, DWARF consumers see an empty range list. This causes significant
slowdowns for objdump and addr2line.
Example:
$ cat foo.c
int foo(int i)
{
return i + 1;
}
int bar(int i)
{
return i + 2;
}
$ gcc -S -dA -g -ffunction-sections foo.c
The resulting assembly code has this:
.text
.Ltext0:
.section.text.foo,"ax",@progbits
.globl foo
.type foo, @function
foo:
.LFB0:
...
.text
.Letext0:
...
.section.debug_ranges,"",@progbits
.Ldebug_ranges0:
.quad .Ltext0 # Offset 0x0
.quad .Letext0
.quad .LFB0 # Offset 0x10
.quad .LFE0
.quad .LFB1 # Offset 0x20
.quad .LFE1
.quad 0x0
.quad 0x0
--
Summary: debug_ranges table contains empty range for unused .text
section with -ffunction-sections
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: ccoutant at gcc dot gnu dot org
ReportedBy: ccoutant at gcc dot gnu dot org
GCC build triplet: x86_64-unknown-linux
GCC host triplet: x86_64-unknown-linux
GCC target triplet: x86_64-unknown-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42454
[Bug debug/42454] debug_ranges table contains empty range for unused .text section with -ffunction-sections
--- Comment #1 from ccoutant at gcc dot gnu dot org 2009-12-21 23:13 --- Created an attachment (id=19363) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19363&action=view) Proposed fix for PR 42454 * dwarf2out.c (dwarf2out_finish): Don't output range for .text section unless .text section was used. Likewise for cold. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42454
[Bug debug/42454] debug_ranges table contains empty range for unused .text section with -ffunction-sections
-- ccoutant at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-21 23:56:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42454
[Bug debug/42454] debug_ranges table contains empty range for unused .text section with -ffunction-sections
--- Comment #2 from ccoutant at gcc dot gnu dot org 2009-12-22 17:38 --- Subject: Bug 42454 Author: ccoutant Date: Tue Dec 22 17:37:57 2009 New Revision: 155402 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155402 Log: PR debug/42454 * dwarf2out.c (dwarf2out_finish): Don't output range for .text section unless .text section was used. Likewise for cold. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42454
[Bug debug/42454] debug_ranges table contains empty range for unused .text section with -ffunction-sections
--- Comment #3 from ccoutant at gcc dot gnu dot org 2009-12-22 17:45 --- Fixed at r155402. -- ccoutant at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42454
[Bug debug/42454] debug_ranges table contains empty range for unused .text section with -ffunction-sections
--- Comment #4 from ccoutant at gcc dot gnu dot org 2009-12-23 00:15 --- Caused a regression: If !text_section_used, would omit the DW_AT_ranges attribute from the compile_unit DIE. -- ccoutant at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42454
[Bug lto/44149] -fuse-linker-plugin lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:610
-- ccoutant at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ccoutant at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-05-17 09:10:19 |2010-05-18 18:15:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44149
[Bug lto/43467] LTO error "bytecode stream: trying to read 0 bytes after the end of the input buffer"
--- Comment #4 from ccoutant at gcc dot gnu dot org 2010-06-03 18:29 --- > Cary - why does lto-plugin get invoked when gold has errors? Gold doesn't stop on these kinds of errors -- it proceeds to the end of the link to try to diagnose as many errors as possible. I'm not sure why a multiple-definition error would cause this problem in lto1, though. Nothing should be preventing the plugin from generating valid IR files, unless the presence of the duplicate definition is causing a different problem inside either the plugin itself or lto1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43467
