[Bug c++/64346] gcc generates incorrect debug info for ctor/dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64346 --- Comment #4 from Cary Coutant ccoutant at gcc dot gnu.org --- I think the problem is that the decloning turns the C1 and C2 ctors into thunks, and GCC doesn't (yet) generate debug info for thunks, so when you inline the C4 into the C1 or C2, and inline that into foo, all that's left in the debug info is the inlined call to the C4 ctor. It looks like -fno-declone-ctors-dtor doesn't work around the problem because the need_alias flag is true, and that forces the decloning in this case. The most expedient approach might be for you to alias the C4/D4 names to the official ones when processing the profile data. Is that feasible?
[Bug other/64046] Malformed .eh_frame generated with LTO, gold and optimization enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64046 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||ccoutant at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |ccoutant at gcc dot gnu.org --- Comment #3 from Cary Coutant ccoutant at gcc dot gnu.org --- See PR gold/17639. Fixed on binutils trunk.
[Bug other/64046] Malformed .eh_frame generated with LTO, gold and optimization enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64046 --- Comment #4 from Cary Coutant ccoutant at gcc dot gnu.org --- (Sorry, that's binutils PR gold/17639.)
[Bug other/63425] Demangler crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63425 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ccoutant at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Cary Coutant ccoutant at gcc dot gnu.org --- This is like a dup of PR 61321. *** This bug has been marked as a duplicate of bug 61321 ***
[Bug other/61321] demangler crash on casts in template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61321 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added CC||riku at multitaction dot com --- Comment #4 from Cary Coutant ccoutant at gcc dot gnu.org --- *** Bug 63425 has been marked as a duplicate of this bug. ***
[Bug middle-end/63244] [4.9/5 regression] internal compiler error: Segmentation fault (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63244 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #20 from Cary Coutant ccoutant at gcc dot gnu.org --- Duplicate of PR 61321.
[Bug middle-end/63244] [4.9/5 regression] internal compiler error: Segmentation fault (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63244 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #21 from Cary Coutant ccoutant at gcc dot gnu.org --- Duplicate of PR 61321. *** This bug has been marked as a duplicate of bug 61321 ***
[Bug other/61321] demangler crash on casts in template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61321 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added CC||nheghathivhistha at gmail dot com --- Comment #5 from Cary Coutant ccoutant at gcc dot gnu.org --- *** Bug 63244 has been marked as a duplicate of this bug. ***
[Bug middle-end/63244] [4.9/5 regression] internal compiler error: Segmentation fault (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63244 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added CC||jason at redhat dot com --- Comment #19 from Cary Coutant ccoutant at gcc dot gnu.org --- I'm pretty sure that Pedro's proposed patch here -- https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02279.html -- will fix this bug.
[Bug middle-end/63244] [4.9 regression] internal compiler error: Segmentation fault (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63244 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ccoutant at gcc dot gnu.org
[Bug debug/60929] [4.8/4.9 regression] ICE in get_ref_die_offset, at dwarf2out.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60929 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Cary Coutant ccoutant at gcc dot gnu.org --- Fixed for 4.10.
[Bug debug/61013] [4.9/4.10 Regression] Option parsing difference between 4.9 and 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013 --- Comment #14 from Cary Coutant ccoutant at gcc dot gnu.org --- Author: ccoutant Date: Wed May 14 21:48:47 2014 New Revision: 210442 URL: http://gcc.gnu.org/viewcvs?rev=210442root=gccview=rev Log: Change -g so that it will override -g1 but not -g3. gcc/ PR debug/61013 * opts.c (common_handle_option): Don't special-case -g. (set_debug_level): Default to at least level 2 with -g. Modified: trunk/gcc/ChangeLog trunk/gcc/opts.c
[Bug debug/61013] [4.9/4.10 Regression] Option parsing difference between 4.9 and 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013 --- Comment #15 from Cary Coutant ccoutant at gcc dot gnu.org --- Author: ccoutant Date: Thu May 15 00:34:20 2014 New Revision: 210456 URL: http://gcc.gnu.org/viewcvs?rev=210456root=gccview=rev Log: Change -g so that it will override -g1 but not -g3. Backported from trunk r210442. gcc/ PR debug/61013 * opts.c (common_handle_option): Don't special-case -g. (set_debug_level): Default to at least level 2 with -g. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/opts.c
[Bug debug/61013] [4.9/4.10 Regression] Option parsing difference between 4.9 and 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |ccoutant at gcc dot gnu.org --- Comment #16 from Cary Coutant ccoutant at gcc dot gnu.org --- Fixed on trunk and on 4.9 branch.
[Bug other/61102] ld --plugin causes binutils gold incremental_test to fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61102 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ccoutant at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |ccoutant at gcc dot gnu.org --- Comment #1 from Cary Coutant ccoutant at gcc dot gnu.org --- I've already fixed the gold testsuite to turn off plugins when necessary: https://sourceware.org/ml/binutils/2014-04/msg00027.html
[Bug debug/61013] [4.9/4.10 Regression] Option parsing difference between 4.9 and 4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013 --- Comment #7 from Cary Coutant ccoutant at gcc dot gnu.org --- (In reply to Andres Freund from comment #2) The point is that this has changed between 4.8 and 4.9... And I don't see anything relevant in http://gcc.gnu.org/gcc-4.9/changes.html Yes, you're right. This change should have been documented there. Sorry! I did ask twice for consensus, and got no objections either time. Our build system adds -g1 to the compile options, before user-supplied options, and if a user adds -g, it's surprising to only get -g1. I wonder if it would be reasonable for -g to set the debug level to max(2, previous level)? I still think the simplicity of -g === -g2 is much better, and it's also much better to be consistent with the -O option. What should the following combinations do? -g1 -g -g1 -g0 -g -g3 -g -g3 -g0 -g -cary
[Bug debug/60929] [4.8/4.9/4.10 regression] ICE in get_ref_die_offset, at dwarf2out.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60929 --- Comment #2 from Cary Coutant ccoutant at gcc dot gnu.org --- Author: ccoutant Date: Fri Apr 25 23:05:14 2014 New Revision: 209812 URL: http://gcc.gnu.org/viewcvs?rev=209812root=gccview=rev Log: Fix a few ICEs and other problems with -fdebug-types-sections. (1) If a function contains a local typedef of an anonymous structure, GCC will generate a typedef DIE in the function, where the typedef DIE points to a structure_type DIE at the top level. That structure_type DIE, if it's a non-POD, can contain ctor and dtor definitions. This causes an assertion in should_move_die_to_comdat to fail, as we have up to now assumed that this could never happen. (2) With --std=c++11, a template parameter can refer to a local type defined within a function. Because that local type doesn't qualify for its own type unit, we copy it as an unworthy type into the type unit that refers to it, but we copy too much, leading to a comdat type unit that contains a DIE with subprogram definitions rather than declarations. These DIEs may have DW_AT_low_pc/high_pc or DW_AT_ranges attributes, and consequently can refer to range list entries that don't get emitted because they're not marked when the compile unit is scanned, eventually causing an undefined symbol at link time. (3) When a class template instantiation is moved into a separate type unit, it can bring along a lot of other referenced types into the type unit, especially if the template is derived from another (large) type that does not have an actually have a type definition in a type unit of its own. When there are many instantiations of the same template, we get a lot of duplication, and in the worst case (a template with several parameters, instantiated multiple times along each dimension), GCC can end up taking a long time and exhausting available memory. This combinatorial explosion is being caused by copy_decls_walk, where it finds a type DIE that is referenced by the type unit, but is not itself a type unit, and copies a declaration for that type into the type unit in order to resolve the reference within the type unit. In the process, copy_decls_walk also copies all of the children of that DIE. In the case of a base class with member function templates, every one of the instantiated member functions is copied into every type unit that references the base class. gcc/ PR debug/60929 * dwarf2out.c (should_move_die_to_comdat): A type definition can contain a subprogram definition, but don't move it to a comdat unit. (clone_as_declaration): Copy DW_AT_abstract_origin attribute. (generate_skeleton_bottom_up): Remove DW_AT_object_pointer attribute from original DIE. (clone_tree_hash): Rename to... (clone_tree_partial): ...this; change callers. Copy DW_TAG_subprogram DIEs as declarations. (copy_decls_walk): Don't copy children of a declaration into a type unit. gcc/testsuite/ PR debug/60929 * g++.dg/debug/dwarf2/dwarf4-nested.C: New test case. * g++.dg/debug/dwarf2/dwarf4-typedef.C: Add -fdebug-types-section flag. Added: trunk/gcc/testsuite/g++.dg/debug/dwarf2/dwarf4-nested.C Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/debug/dwarf2/dwarf4-typedef.C
[Bug debug/60929] [4.8/4.9/4.10 regression] ICE in get_ref_die_offset, at dwarf2out.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60929 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ccoutant at gcc dot gnu.org Target Milestone|4.8.3 |4.9.1
[Bug debug/55794] FAIL: g++.dg/debug/dwarf2/non-virtual-thunk.C -std=gnu++98 and -std=gnu++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55794 --- Comment #4 from Cary Coutant ccoutant at gcc dot gnu.org --- On hppa64-hp-hpux11.11, I don't see any debug information at all unless I add -g to compile options. The dg-options line adds -g2 -dA to the compile options. In the assembly output you posted, the two thunks don't have any line number info at all: .globl_ZThn16_N1CD1Ev .type_ZThn16_N1CD1Ev, @function _ZThn16_N1CD1Ev: .PROC .CALLINFO FRAME=0,NO_CALLS .ENTRY b _ZN1CD2Ev ldo -16(%r26),%r26 .EXIT .PROCEND .size_ZThn16_N1CD1Ev, .-_ZThn16_N1CD1Ev .globl_ZThn16_N1CD0Ev .type_ZThn16_N1CD0Ev, @function _ZThn16_N1CD0Ev: .PROC .CALLINFO FRAME=0,NO_CALLS .ENTRY b _ZN1CD0Ev ldo -16(%r26),%r26 .EXIT .PROCEND .size_ZThn16_N1CD0Ev, .-_ZThn16_N1CD0Ev The patch that this test case was part of was supposed to fix that problem by adding a call to debug_hooks-source_line from assemble_thunk. Either the PA code generator doesn't go through assemble_thunk when generating these thunks, or the call to debug_hooks-source_line is being ignored. Richard Henderson expressed some concerns here: http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00312.html I convinced him that the patch was OK, but perhaps he was right, and something more is needed for PA.
[Bug debug/55794] FAIL: g++.dg/debug/dwarf2/non-virtual-thunk.C -std=gnu++98 and -std=gnu++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55794 --- Comment #5 from Cary Coutant ccoutant at gcc dot gnu.org --- (In reply to Janis Johnson from comment #1) For arm-none-eabi the line that is recorded is 33 rather than 30. I see from gcc-testresults that the test also fails for moxie-elf, bfin-rtems, and m32r-rtems. The code at line 33 should be the constructor. Look for the thunks _ZThn16_N1CD0Ev and _ZThn16_N1CD1Ev. They should have line 30, but I'd guess the line number info is simply missing from those thunks. If they say line 33, something else is wrong.
[Bug other/59195] C++ demangler handles conversion operator incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59195 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Cary Coutant ccoutant at gcc dot gnu.org --- Fixed at r205292.
[Bug other/59195] C++ demangler handles conversion operator incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59195 --- Comment #2 from Cary Coutant ccoutant at gcc dot gnu.org --- Author: ccoutant Date: Fri Nov 22 22:25:49 2013 New Revision: 205292 URL: http://gcc.gnu.org/viewcvs?rev=205292root=gccview=rev Log: Fix demangler to handle conversion operators correctly. libiberty/ PR other/59195 * cp-demangle.c (struct d_info_checkpoint): New struct. (struct d_print_info): Add current_template field. (d_operator_name): Set flag when processing a conversion operator. (cplus_demangle_type): When processing template-args for a conversion operator, backtrack if necessary. (d_expression_1): Renamed from d_expression. (d_expression): New wrapper around d_expression_1. (d_checkpoint): New function. (d_backtrack): New function. (d_print_init): Initialize current_template. (d_print_comp): Set current_template. (d_print_cast): Put current_template in scope for printing conversion operator name. (cplus_demangle_init_info): Initialize is_expression and is_conversion. * cp-demangle.h (struct d_info): Add is_expression and is_conversion fields. * testsuite/demangle-expected: New test cases. Modified: trunk/libiberty/ChangeLog trunk/libiberty/cp-demangle.c trunk/libiberty/cp-demangle.h trunk/libiberty/testsuite/demangle-expected
[Bug other/59195] New: C++ demangler handles conversion operator incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59195
Bug ID: 59195
Summary: C++ demangler handles conversion operator incorrectly
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: ccoutant at gcc dot gnu.org
Consider this simple source:
struct C {
C(int i_) : i(i_) { }
int i;
};
struct A {
A() : i(0) { }
template typename U
explicit operator U();
int i;
};
void foo()
{
A ai;
C c = (C)ai;
}
The conversion operator in A mangles to _ZN1AcvT_I1CEEv, which
demangles to:
A::operator CC()
(I think this would be better as A::operator C(), but let's
leave that aside for now.)
That looks OK, but not if you dig deeper. The demangler is
parsing this name as follows:
typed name
qualified name
name 'A'
cast
template
template parameter 0
template argument list
name 'C'
function type
argument list
A::operator CC()
It's parsing the T_ as a template-template-param, not a
template-param. It should really be parsing it as:
typed name
template
qualified name
name 'A'
cast
template parameter 0
template argument list
name 'C'
function type
argument list
A::operator CC()
The template argument list actually belongs with the
qualified-name, not with the template parameter.
The basic problem is an ambiguity in the grammar for mangled
names. Consider the following two derivations:
(1) nested-name
- template-prefix template-args
- prefix template-unqualified-name template-args
- unqualified-name template-unqualified-name
template-args
- source-name template-unqualified-name template-args
- source-name operator-name template-args
- source-name cv type template-args
- source-name cv template-template-param
template-args template-args
(2) nested-name
- template-prefix template-args
- prefix template-unqualified-name template-args
- unqualified-name template-unqualified-name
template-args
- source-name template-unqualified-name template-args
- source-name operator-name template-args
- source-name cv type template-args
- source-name cv template-param template-args
When you get to the T_, there's no way to know if it's a
template-param or a template-template-param. The parser in
cp-demangle.c, in cplus_demangle_type, looks ahead to
disambiguate the two. If it sees an 'I', it assumes that it's a
template-template-param, and it greedily consumes the
template-args.
In this particular case, it's wrong, but it gets the right answer
because of a hack in d_print_cast, which takes the template
arguments under the cast operator, and places them in scope
before resolving the T_ reference.
It doesn't take much to break that hack, though. Let's throw in a
pointer:
struct C {
C(int i_) : i(i_) { }
int i;
};
struct A {
A() : i(0) { }
template typename U
explicit operator U*();
int i;
};
void foo()
{
A ai;
C* c = (C*)ai;
}
Now we get the mangled name _ZN1AcvPT_I1CEEv, which the
demangler fails on:
typed name
qualified name
name 'A'
cast
pointer
template
template parameter 0
template argument list
name 'C'
function type
argument list
Failed: _ZN1AcvPT_I1CEEv
This name ought to be parsed as follows:
typed name
template
qualified name
name 'A'
cast
pointer
template parameter 0
template argument list
name 'C'
function type
argument list
A::operator C*C()
(This incorrect parsing can also lead to some other subtle types
of failures, because substitutions can be numbered in the wrong
order. See the long example that started me on this investigation
at the end.)
Now let's add a real template template parameter:
template typename T
struct C {
C(T i_) : i(i_) { }
T i;
};
struct A {
A() : i(0) { }
template templatetypename U class V
operator Vint();
int i;
};
void foo()
{
A ai;
Cint c = (Cint)ai;
}
The conversion operator is now _ZN1AcvT_IiEI1CEEv, and the
demangler gives us this:
typed name
template
qualified name
name 'A'
cast
template
template parameter 0
template argument list
builtin type int
template argument list
name 'C'
function type
argument list
A::operator intintC()
The derivation is actually correct this time, because we really
do have a template-template-param, but the hack in d_print_cast
causes it to substitute the wrong type for T_.
I'm pretty sure that the ambiguity
[Bug other/59195] C++ demangler handles conversion operator incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59195 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-11-19 Assignee|unassigned at gcc dot gnu.org |ccoutant at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Cary Coutant ccoutant at gcc dot gnu.org --- Created attachment 31253 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31253action=edit Proposed patch
[Bug c++/58591] GCC emits bad mangling for template function with a parameter pack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58591 --- Comment #3 from Cary Coutant ccoutant at gcc dot gnu.org --- I think the template argument descriptors should be I1AJiiEE. This produces a demangling that looks right: $ c++filt _Z9ConstructI1AJiiEEvPT_DpOT0_ void ConstructA, int, int(A*, int, int) And running this test case through LLVM, that's the mangled name it produces.
[Bug c++/51322] [C++11] wrong mangling with argument packs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51322 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added CC||ccoutant at gcc dot gnu.org --- Comment #4 from Cary Coutant ccoutant at gcc dot gnu.org --- *** Bug 58591 has been marked as a duplicate of this bug. ***
[Bug c++/58591] GCC emits bad mangling for template function with a parameter pack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58591 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Cary Coutant ccoutant at gcc dot gnu.org --- Never mind, I see now that this was fixed with -fabi-version=6. *** This bug has been marked as a duplicate of bug 51322 ***
[Bug c++/58591] New: GCC emits bad mangling for template function with a parameter pack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58591 Bug ID: 58591 Summary: GCC emits bad mangling for template function with a parameter pack Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ccoutant at gcc dot gnu.org Created attachment 30944 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30944action=edit Reduced test case This is reduced from bits/stl_construct.h. Compiling the attached file with: $ g++ -S -std=c++11 mangle-test.cc Produces the following mangled name for the function Construct: _Z9ConstructI1AIiiEEvPT_DpOT0_ This cannot be demangled, because the T0_ reference at the end refers to a non-existent second template parameter. Removing the whole parameter pack from the mangling reveals a bogus mangling in the template parameter section: $ c++filt _Z9ConstructI1AIiiEEvPT_ void ConstructAint, int (Aint, int*) The type A is not a template -- the two ints together form the parameter pack that is the second template parameter.
[Bug c++/58591] GCC emits bad mangling for template function with a parameter pack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58591 --- Comment #2 from Cary Coutant ccoutant at gcc dot gnu.org --- I *think* the correct mangling should be this: $ c++filt _Z9ConstructI1AiiEvPT_DpOT0_ void ConstructA, int, int(A*, (int)...)
[Bug rtl-optimization/57451] Incorrect debug ranges emitted for -freorder-blocks-and-partition -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57451
--- Comment #4 from Cary Coutant ccoutant at gcc dot gnu.org ---
The problem is a lexical block in main() that appears to be getting split by
-freorder-blocks-and-partition, but when debug info is emitted during
rest_of_handle_final(), this particular lexical block still appears to be a
single block -- BLOCK_FRAGMENT_CHAIN is NULL, so the DWARF output code decides
that it can emit a DW_AT_low_pc/high_pc pair instead of a DW_AT_ranges. The
DW_AT_high_pc is now being output relative to DW_AT_low_pc, so we see an
assembly expression .LBE14 - .LBB14, which are labels attached to the block
start and block end, and should be in the same section.
Here's the block:
(gdb) p stmt
$1 = (tree) 0x75f4c4b0
(gdb) pt
warning: Expression is not an assignment (and might have no effect)
block 0x75f4c4b0 asm_written used
vars var_decl 0x7608bc78 e
type reference_type 0x7609b930 type record_type 0x7608e9d8
MyException
sizes-gimplified unsigned DI
size integer_cst 0x75f24dc0 constant 64
unit size integer_cst 0x75f24de0 constant 8
align 64 symtab 0 alias set -1 canonical type 0x7609b930
readonly tree_1 tree_3 unsigned decl_5 DI file pr49115.C line 21 col 25
size integer_cst 0x75f24dc0 64 unit size integer_cst 0x75f24de0 8
align 64 context function_decl 0x76096f00 main
supercontext block 0x760c00f0 asm_written used
vars var_decl 0x7608bb48 data type record_type 0x7608ec78
Data
used tree_1 tree_3 decl_5 SI file pr49115.C line 18 col 8
size integer_cst 0x75f42140 constant 32
unit size integer_cst 0x75f42160 constant 4
align 128 context function_decl 0x76096f00 main
(reg/v:SI 64 [ data ])
supercontext block 0x75f4c550 asm_written used supercontext
function_decl 0x76096f00 main
subblocks block 0x75f4c500 asm_written used vars var_decl
0x7608bb48 data supercontext block 0x75f4c550 subblocks block
0x75f4c4b0 chain block 0x760c00f0
(gdb) p stmt-block
$2 = {base = {code = BLOCK, side_effects_flag = 0, constant_flag = 0,
addressable_flag = 0,
volatile_flag = 0, readonly_flag = 0, asm_written_flag = 1, nowarning_flag
= 0, visited = 0,
used_flag = 1, nothrow_flag = 0, static_flag = 0, public_flag = 0,
private_flag = 0,
protected_flag = 0, deprecated_flag = 0, default_def_flag = 0, u = {bits =
{lang_flag_0 = 0,
lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0,
lang_flag_5 = 0,
lang_flag_6 = 0, saturating_flag = 0, unsigned_flag = 0, packed_flag =
0, user_align = 0,
nameless_flag = 1, spare0 = 0, spare1 = 0, address_space = 0}, length =
2048,
version = 2048}}, chain = 0x0, abstract_flag = 0, block_num = 14, locus =
0,
vars = 0x7608bc78, nonlocalized_vars = 0x0, subblocks = 0x0, supercontext
= 0x760c00f0,
abstract_origin = 0x0, fragment_origin = 0x0, fragment_chain = 0x0}
Here's the fragment of assembly code between .LBB14 and .LBE14:
.LBB14:
# pr49115.C:21
.loc 1 21 0
call__cxa_begin_catch
.LVL7:
call__cxa_end_catch
.LVL8:
.p2align 4,,5
# SUCC: 3 [100.0%] count:1
jmp .L15
.cfi_endproc
.section.text.unlikely
.cfi_startproc
.cfi_personality 0x3,__gxx_personality_v0
.cfi_lsda 0x3,.LLSDAC4
# BLOCK 6 freq:5000 seq:4
# PRED: 4 [50.0%] (CROSSING,CAN_FALLTHRU)
.L14:
.cfi_def_cfa_offset 16
.p2align 4,,8
.LEHB1:
# SUCC:
call_Unwind_Resume
.LEHE1:
.LVL9:
.LBE14:
.LBE15:
.cfi_endproc
You can see that the block from .LBB14 to .LBE14 has been split across two
sections. In order for dwarf2out to generate the proper debug info,
BLOCK_FRAGMENT_CHAIN(stmt) needs to be non-NULL. I'm not sure why that's not
happening when the block is split.
[Bug rtl-optimization/57451] Incorrect debug ranges emitted for -freorder-blocks-and-partition -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57451 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added CC||ccoutant at gcc dot gnu.org --- Comment #2 from Cary Coutant ccoutant at gcc dot gnu.org --- I'll take a look, but at first glance it looks like have_multiple_function_sections isn't being set in dwarf2out.c, which leads it to assume that it can use symbol - symbol expressions in the range lists. That flag is set by the switch_text_section hook, which is called from final_scan_insn when it sees a NOTE_INSN_SWITCH_TEXT_SECTIONS insn. When -freorder-blocks-and-partitions is turned on, is such a NOTE being emitted?
[Bug driver/57238] GCC passes --gdwarf2 to assembler despite -gdwarf-4 on command line
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57238 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added CC||ccoutant at gcc dot gnu.org --- Comment #4 from Cary Coutant ccoutant at gcc dot gnu.org --- There's no reason to expect that -gdwarf-4 will automatically get you an indirect string here -- DW_FORM_strp was just as valid in DWARF 2 and 3 as it is in DWARF 4. Here the assembler is simply making the choice to put the string inline. I'm not sure if that's because there's no support for indirect strings at all in the assembler or because it doesn't expect the comp_dir string to be duplicated. I think what you're really asking for is to have the assembler generate indirect strings. That can be done without upgrading to DWARF 4. While I do agree that the assembler ought to be able to generate DWARF 4 by now, for the kind of debug output that the assembler generates, I don't think it's really all that important. -cary
[Bug debug/56805] DW_TAG_typedef missing when -fdebug-types-section is used (and -fno-eliminate-unused-debug-types)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56805 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added CC||ccoutant at gcc dot gnu.org --- Comment #2 from Cary Coutant ccoutant at gcc dot gnu.org 2013-04-02 17:40:09 UTC --- When generating separate type units with -fdebug-types-section, we always prune unused types after splitting the types out. As implemented, I think -fdebug-types-section is incompatible with -fno-eliminate-unused-debug-types, and a diagnostic should be printed. How important is it that these two options work together?
[Bug debug/56805] DW_TAG_typedef missing when -fdebug-types-section is used (and -fno-eliminate-unused-debug-types)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56805 --- Comment #4 from Cary Coutant ccoutant at gcc dot gnu.org 2013-04-02 20:34:57 UTC --- In GCC 4.6, type sections were the default for -gdwarf-4, but -gdwarf-2 was still the default for 4.6, I think. If you explicitly ask for -gdwarf-4, you can also add -gstrict-dwarf and it will not generate the type sections. The -fdebug-types-section flag was added in 4.7 when -gdwarf-4 was made the default. So if all you need is DWARF-4 with GCC 4.6 and -fno-eliminate-unused-types, but you don't need type sections, just add -gstrict-dwarf.
[Bug debug/56805] DW_TAG_typedef missing when -fdebug-types-section is used (and -fno-eliminate-unused-debug-types)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56805 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-04-02 AssignedTo|unassigned at gcc dot |ccoutant at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug debug/55328] ICE: in output_addr_table_entry, at dwarf2out.c:21780 with -gsplit-dwarf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55328 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ccoutant at gcc dot gnu.org Resolution||FIXED --- Comment #3 from Cary Coutant ccoutant at gcc dot gnu.org 2013-03-05 19:27:27 UTC --- Fixed at r193515.
[Bug debug/55364] ICE: in remove_addr_table_entry, at dwarf2out.c:4201 with -O -gsplit-dwarf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55364 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |ccoutant at gcc dot gnu.org |gnu.org |
[Bug debug/55364] ICE: in remove_addr_table_entry, at dwarf2out.c:4201 with -O -gsplit-dwarf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55364 --- Comment #2 from Cary Coutant ccoutant at gcc dot gnu.org 2013-03-05 23:08:52 UTC --- Author: ccoutant Date: Tue Mar 5 23:08:45 2013 New Revision: 196480 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196480 Log: gcc/ PR debug/55364 * dwarf2out.c (resolve_addr): Don't call remove_loc_list_addr_table_entries a second time for the same expression. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug debug/55364] ICE: in remove_addr_table_entry, at dwarf2out.c:4201 with -O -gsplit-dwarf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55364 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Cary Coutant ccoutant at gcc dot gnu.org 2013-03-05 23:11:53 UTC --- Fixed at r196480.
[Bug driver/55781] New: -shared-libgcc does not completely undo -static-libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55781 Bug #: 55781 Summary: -shared-libgcc does not completely undo -static-libgcc Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassig...@gcc.gnu.org ReportedBy: ccout...@gcc.gnu.org In the gold testsuite, I need to link with a shared libgcc, but the top-level configure now passes in -static-libgcc to all $(COMPILE) and $(CXX_COMPILE) actions. I tried to undo that by adding -shared-libgcc to the command line, but it doesn't quite erase the effects of -static-libgcc. Running gcc without either option gives me these link options: .../collect2 ... -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc ... Running gcc with both -static-libgcc and -shared-libgcc gives me this: .../collect2 ... -lstdc++ -lm -lgcc -lgcc_eh -lc -lgcc -lgcc_eh ... Reproduced with 4.7 as well.
[Bug driver/55782] New: GCC needs a -shared-libstdc++ option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55782 Bug #: 55782 Summary: GCC needs a -shared-libstdc++ option Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassig...@gcc.gnu.org ReportedBy: ccout...@gcc.gnu.org The top-level configure for gcc and sources now turns on -static-libstdc++ option, and I need to be able to add an option to turn that back off. Unfortunately, there is no -shared-libstdc++ option.
[Bug debug/55231] ICE in output_addr_table_entry, at dwarf2out.c:21782 with -gsplit-dwarf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55231 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Cary Coutant ccoutant at gcc dot gnu.org 2012-11-15 00:18:37 UTC --- Duplicate of PR debug/55328, fixed at r193515. *** This bug has been marked as a duplicate of bug 55328 ***
[Bug debug/55328] ICE: in output_addr_table_entry, at dwarf2out.c:21780 with -gsplit-dwarf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55328 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added CC||markus at trippelsdorf dot ||de --- Comment #2 from Cary Coutant ccoutant at gcc dot gnu.org 2012-11-15 00:18:37 UTC --- *** Bug 55231 has been marked as a duplicate of this bug. ***
[Bug debug/55231] ICE in output_addr_table_entry, at dwarf2out.c:21782 with -gsplit-dwarf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55231 --- Comment #3 from Cary Coutant ccoutant at gcc dot gnu.org 2012-11-15 00:34:56 UTC --- (In reply to comment #1) Another issue: markus@x4 ~ % c++ -c -O0 -gsplit-dwarf test.ii -o /dev/null /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../x86_64-pc-linux-gnu/bin/objcopy: Warning: '/dev/null' is not an ordinary file I'm not sure what the right thing to do about this would be -- is there a portable way to check whether the -o option names a real filename or not? Is your intent that neither .o nor .dwo is generated? Why use -gsplit-dwarf in that case? I'm inclined to document this away. If you care, please clone this into a new bug report.
[Bug debug/55063] [4.8 Regression] Thousands of failures in the libstdc++-v3 tests after revision 192739
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55063 --- Comment #7 from Cary Coutant ccoutant at gcc dot gnu.org 2012-10-25 18:30:34 UTC --- Author: ccoutant Date: Thu Oct 25 18:30:27 2012 New Revision: 192820 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192820 Log: gcc/ PR debug/55063 * dwarf2out.c (prune_unused_types_prune): Check whether DIE is already a declaration. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug debug/55063] [4.8 Regression] Thousands of failures in the libstdc++-v3 tests after revision 192739
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55063 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||ccoutant at gcc dot gnu.org Resolution||FIXED AssignedTo|unassigned at gcc dot |ccoutant at gcc dot gnu.org |gnu.org | --- Comment #8 from Cary Coutant ccoutant at gcc dot gnu.org 2012-10-25 18:33:24 UTC --- I've committed a fix at r192820. http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02316.html
[Bug debug/53235] [4.8 Regression] 20120504 broke -fdebug-types-section
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53235 --- Comment #13 from Cary Coutant ccoutant at gcc dot gnu.org 2012-09-06 03:34:27 UTC --- Author: ccoutant Date: Thu Sep 6 03:34:22 2012 New Revision: 191005 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191005 Log: 2012-09-05 Cary Coutant ccout...@gmail.com Backport trunk patch to fix a problem where type signature does not include the type's context. 2012-07-19 Jason Merrill ja...@redhat.com gcc/ PR debug/53235 * dwarf2out.c (get_die_parent): New. (generate_type_signature): Use it. gcc/testsuite/ * g++.dg/debug/dwarf2/nested-4.C: New. Added: branches/google/gcc-4_7/gcc/testsuite/g++.dg/debug/dwarf2/nested-4.C Modified: branches/google/gcc-4_7/gcc/ChangeLog.google-4_7 branches/google/gcc-4_7/gcc/dwarf2out.c branches/google/gcc-4_7/gcc/testsuite/ChangeLog.google-4_7
[Bug debug/53754] [4.8 Regression][lto] ICE in lhd_decl_printable_name, at langhooks.c:222 (with -g)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53754 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |ccoutant at gcc dot gnu.org |gnu.org | --- Comment #4 from Cary Coutant ccoutant at gcc dot gnu.org 2012-06-25 21:19:17 UTC --- Created attachment 27705 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27705 Patch to fix ICE with -g -flto and anonymous namespace You can't delay producing pubnames this way with LTO. Please fix. The obvious problem is that we're calling langhooks.dwarf_name (in gen_namespace_die) for an anonymous namespace, even with the default -gno-pubnames. I can fix that by adding a check for want_pubnames just before the call to add_pubname_string, as in the patch below. But this is still going to ICE if you turn on -gpubnames with -lto. The only way I can think of to fix that is relax the assert in lhd_decl_printable_name, and just have it return an empty string in the DECL_NAMELESS case. That will not produce the right results for an anonmyous namespace, but without front-end langhooks available to us (and until we implement the lazy debug plan), how can we do better? How much is expected to work today with LTO and -g? Aren't we still stuck with calling langhooks from dwarf2out.c back-end routines? I can understand that we don't want to ICE, but what guarantees do we make about debug info? -cary
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #79 from Cary Coutant ccoutant at gcc dot gnu.org 2012-04-17 18:00:41 UTC --- (In reply to comment #77) I believe .init_array keeps the same order of .ctors within the same translation unit. The proposed --reverse-init-array switch will only reverse the order across translation units, while keeping the same order within translation unit. Is this correct? Yes. If you have translation unit A with .ctors entries A1 and A2, and translation unit B with .ctors entries B1 and B2, we'll build a .init_array section with: B1 B2 A1 A2 As Paul noted, this is a moot point in practice for .ctors, since GCC emits only a single .ctors entry per TU, but it could be significant for assembly code or for TUs with .init_array sections. -cary
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added CC||ppluzhnikov at google dot ||com --- Comment #74 from Cary Coutant ccoutant at gcc dot gnu.org 2012-04-17 01:21:47 UTC --- We still have an unresolved issue here: we're effectively reversing the order in which the ctors are run across translation units. While explicitly undefined by any standard, it was mentioned upthread that this would probably break a lot of code that depended on ctors for later translation units (e.g., a statically-linked C++ library) running before those for earlier translation units. And, in fact, we have been finding lots of such code. We've temporarily worked around it by configuring GCC to continue to use .ctors sections, and by turning off --ctors-in-init-array in the linker, but I'd think it would be nice to fix this. I'd like to propose a --reverse-init-array option to the linker that would reverse the contributions to the .init_array section relative to one another (but not the actual contents of each contribution). With this option, the .init_array entries for translation unit A would come after those for translation unit B, when A comes before B on the link command. This would still conform to the standards, but would provide a more reasonable ordering, since it is natural to expect initializers for dependent libraries to execute before those for code that depends on them (as is the case for shared libraries already). As I recall the discussions from years ago when we first added .init_array, I think we would have always preferred to have the dynamic loader execute the .init_array entries in reverse, but we were trying to preserve the behavior that had always been observed with the old .init section (which, obviously, could not execute in reverse). I believe that was the original reason (or at least part of it) that GCC put ctors in a separate section rather than using .init or .init_array. Now that we're moving .ctors into .init_array, I think it's more important to preserve the old behavior of ctors rather than the old behavior of .init fragments. HJ, if I add this option to gold, would you add it to ld? If this is OK with everyone, we can then discuss whether or not the option should be on by default. -cary
[Bug debug/45682] missing namespace parent die when using -gdwarf-4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45682 --- Comment #4 from Cary Coutant ccoutant at gcc dot gnu.org 2012-01-20 18:57:49 UTC --- Author: ccoutant Date: Fri Jan 20 18:57:44 2012 New Revision: 183348 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183348 Log: 2012-01-19 Cary Coutant ccout...@google.com Dodji Seketeli do...@redhat.com gcc/ PR debug/45682 * dwarf2out.c (copy_declaration_context): Return ref to parent of declaration DIE, if necessary. (remove_child_or_replace_with_skeleton): Add new parameter; update caller. Place skeleton DIE under parent DIE of original declaration. Move call to copy_declaration_context to here ... (break_out_comdat_types): ... from here. gcc/testsuite/ PR debug/45682 * g++.dg/debug/dwarf2/nested-3.C: New test. Added: trunk/gcc/testsuite/g++.dg/debug/dwarf2/nested-3.C Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog
[Bug debug/45682] missing namespace parent die when using -gdwarf-4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45682 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED AssignedTo|dodji at gcc dot gnu.org|ccoutant at gcc dot gnu.org --- Comment #5 from Cary Coutant ccoutant at gcc dot gnu.org 2012-01-20 19:02:26 UTC --- Fixed for GCC 4.7.
[Bug debug/45682] missing namespace parent die when using -gdwarf-4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45682 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added CC||ccoutant at gcc dot gnu.org --- Comment #3 from Cary Coutant ccoutant at gcc dot gnu.org 2012-01-07 01:19:07 UTC --- I don't think Dodji's patch actually fixes the problem described here. This one should: http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00346.html -cary
[Bug c++/40831] g++ generated symbols for cloned function that be demangled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831
--- Comment #14 from Cary Coutant ccoutant at gcc dot gnu.org 2011-09-26
18:29:52 UTC ---
Author: ccoutant
Date: Mon Sep 26 18:29:46 2011
New Revision: 179209
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179209
Log:
include/ChangeLog:
PR 40831
* demangle.h (enum demangle_component_type): Add
DEMANGLE_COMPONENT_CLONE.
libiberty/ChangeLog:
PR 40831
* cp-demangle.c (d_make_comp): Add new component type.
(cplus_demangle_mangled_name): Check for clone suffixes.
(d_parmlist): Don't error out if we see '.'.
(d_clone_suffix): New function.
(d_print_comp): Print info for clone suffixes.
* testsuite/demangle-expected: Add new testcases.
Modified:
branches/gcc-4_6-branch/ (props changed)
branches/gcc-4_6-branch/include/ChangeLog
branches/gcc-4_6-branch/include/demangle.h
branches/gcc-4_6-branch/libiberty/ChangeLog
branches/gcc-4_6-branch/libiberty/cp-demangle.c
branches/gcc-4_6-branch/libiberty/testsuite/demangle-expected
Propchange: branches/gcc-4_6-branch/
('svn:mergeinfo' added)
[Bug c++/40831] g++ generated symbols for cloned function that be demangled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #15 from Cary Coutant ccoutant at gcc dot gnu.org 2011-09-26 18:33:38 UTC --- Fixed on trunk and in gcc-4_6-branch.
[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |ccoutant at gcc dot gnu.org |gnu.org | --- Comment #23 from Cary Coutant ccoutant at gcc dot gnu.org 2011-09-26 20:42:20 UTC --- Gold patch posted: http://sourceware.org/ml/binutils/2011-09/msg00191.html -cary
[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #24 from Cary Coutant ccoutant at gcc dot gnu.org 2011-09-26 23:32:17 UTC --- Author: ccoutant Date: Mon Sep 26 23:32:13 2011 New Revision: 179220 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179220 Log: PR lto/47247 * plugin-api.h (enum ld_plugin_symbol_resolution): Add LDPR_PREVAILING_DEF_IRONLY_EXP. (enum ld_plugin_tag): Add LDPT_GET_SYMBOLS_V2. Modified: trunk/include/ChangeLog trunk/include/plugin-api.h
[Bug c++/40831] g++ generated symbols for cloned function that be demangled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831 --- Comment #12 from Cary Coutant ccoutant at gcc dot gnu.org 2011-09-23 21:39:13 UTC --- Author: ccoutant Date: Fri Sep 23 21:39:10 2011 New Revision: 179132 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179132 Log: include/ChangeLog: PR 40831 * demangle.h (enum demangle_component_type): Add DEMANGLE_COMPONENT_CLONE. libiberty/ChangeLog: PR 40831 * cp-demangle.c (d_make_comp): Add new component type. (cplus_demangle_mangled_name): Check for clone suffixes. (d_parmlist): Don't error out if we see '.'. (d_clone_suffix): New function. (d_print_comp): Print info for clone suffixes. * testsuite/demangle-expected: Add new testcases. Modified: trunk/include/ChangeLog trunk/include/demangle.h trunk/libiberty/ChangeLog trunk/libiberty/cp-demangle.c trunk/libiberty/testsuite/demangle-expected
[Bug c++/40831] g++ generated symbols for cloned function that be demangled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added Attachment #23439|0 |1 is obsolete|| --- Comment #11 from Cary Coutant ccoutant at gcc dot gnu.org 2011-08-20 00:54:56 UTC --- Created attachment 25060 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25060 Updated patch to demangle cloned function symbols This patch generalizes the clone suffix recognition, so it accepts a series of suffixes of the form [.clonetype][.nnn]
[Bug debug/47393] g++.dg/debug/dwarf2/icf.C FAILs on IRIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47393 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added CC||ccoutant at gcc dot gnu.org --- Comment #8 from Cary Coutant ccoutant at gcc dot gnu.org 2011-07-22 16:49:11 UTC --- Why not just remove the test entirely instead of XFAIL it? The functionality that it was testing has been removed and replaced with something else.
[Bug c++/40831] g++ generated symbols for cloned function that be demangled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831 --- Comment #9 from Cary Coutant ccoutant at gcc dot gnu.org 2011-02-23 18:30:19 UTC --- Does not work for `_Z3fooi.1988' or `_Z3fooi.part.9.165493.constprop.775.31805'. Where does the _Z3fooi.1988 style come from? I guess your second example is from a cloned function (due to partial inlining) that got cloned again (due to constant propagation), but why are there two numbers on each?
[Bug c++/40831] g++ generated symbols for cloned function that be demangled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |ccoutant at gcc dot gnu.org |gnu.org | --- Comment #7 from Cary Coutant ccoutant at gcc dot gnu.org 2011-02-23 02:00:08 UTC --- Created attachment 23439 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23439 Patch to add demangler support for cloned function symbols include/ChangeLog: PR 40831 * demangle.h (enum demangle_component_type): Add DEMANGLE_COMPONENT_CLONE, DEMANGLE_COMPONENT_CONSTPROP_CLONE, DEMANGLE_COMPONENT_ISRA_CLONE, DEMANGLE_COMPONENT_PART_CLONE. libiberty/ChangeLog: PR 40831 * cp-demangle.c (struct clone_suffix_list): New type. (d_make_comp): Add new component types. (cplus_demangle_mangled_name): Check for clone suffixes. (d_parmlist): Don't error out if we see '.'. (clone_suffixes): New array. (d_clone_suffix): New function. (d_print_comp): Print info for clone suffixes. * testsuite/demangle-expected: Add new testcases.
[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added CC||ccoutant at gcc dot gnu.org --- Comment #8 from Cary Coutant ccoutant at gcc dot gnu.org 2011-01-10 18:50:37 UTC --- The plugin interface needs LDPR_PREVAILING_DEF_IRONLY_BUT_EXPORTED (but with a shorter name). For discussion, see: http://gcc.gnu.org/ml/gcc/2010-12/msg00035.html http://gcc.gnu.org/ml/gcc/2010-12/msg00043.html http://gcc.gnu.org/ml/gcc/2010-12/msg00045.html
[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #9 from Cary Coutant ccoutant at gcc dot gnu.org 2011-01-10 19:07:54 UTC --- I've added a new disposition code LDPR_PREVAILING_DEF_IRONLY_EXP and a new version of the GET_SYMBOLS interface to the API specification on the wiki: http://gcc.gnu.org/wiki/whopr/driver How does that look? -cary
[Bug libstdc++/44952] #include iostream implies global constructor.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44952 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added CC||ccoutant at gcc dot gnu.org --- Comment #15 from Cary Coutant ccoutant at gcc dot gnu.org 2010-12-14 18:50:11 UTC --- (In reply to comment #13) So reopening for this enhancement... Another alternative would be some .init.first array or something similar which would contain pointers to functions to be run as early constructors and linker would remove duplicates in it and put it at the beginning of .init_array section. For ELF targets, this is what DT_PREINIT_ARRAY is for. http://www.sco.com/developers/gabi/latest/ch5.dynamic.html#init_fini -cary
[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #50 from Cary Coutant ccoutant at gcc dot gnu.org 2010-12-13 20:24:43 UTC --- Sorry for jumping in so late here, but it sounds like the conclusions here match my recollections: - We added .init_array/.fini_array in order to blend the SVR4 version of .init, which contained actual code, with the HP-UX version, which contained function pointers and used a DT_INIT_SZ entry in the dynamic array rather than prologue and epilogue pieces contributed from crt*.o files. The HP-UX version was seen as an improvement, but it wasn't compatible, so we renamed the sections and the dynamic table entries so that the two versions could live side-by-side and implementations could transition slowly from one to the other. - On HP-UX, we used .init/.init_array for static constructors, and they registered the corresponding static destructors on a special atexit list, rather than adding destructors to .fini_array, so that we could handle destructors on dlclose() events properly (subject to your interpretation of properly in that context) [http://www.codesourcery.com/public/cxx-abi/abi.html#dso-dtor]. - Because .init was always executed from beginning to end (as code, there really wasn't much alternative), so was .init_array. - The gABI guaranteed that the init sections from a DT_NEEDED entry would execute before those from the library containing that DT_NEEDED entry (reverse topological order). - Constructor execution order within a translation unit was guaranteed, but there was no specified ordering between translation units within an executable or shared library (although in practice it was link order). Those of us in the discussions were mostly pro-shared library, so we weren't too worried about running initializers backwards with respect to link order. The C++ ABI group specified a way to record the constructor priorities, different from the .ctors.n method used by gcc [http://www.codesourcery.com/public/cxx-abi/abi.html#ctor-order]. If gcc switches from .ctors to .init_array, it needs to make sure to generate the constructors in forward order within the TU, rather than backwards order as it does in the .ctors section. I didn't see anything in HJ's patch that does that. We will still have an incompatibility with constructor order across TUs within an executable or shared library. The new order may be just as legal as the previous order according to the ABI and the language spec, but it will almost certainly cause previously-working code to fail. If we offer an option to switch from .ctors to .init_array, and encourage such code to use explicit priorities where order really matters, I'd think that would be OK.
[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added CC||ccoutant at gcc dot gnu.org --- Comment #52 from Cary Coutant ccoutant at gcc dot gnu.org 2010-12-13 20:41:46 UTC --- (In reply to comment #51) If gcc switches from .ctors to .init_array, it needs to make sure to generate the constructors in forward order within the TU, rather than backwards order as it does in the .ctors section. I didn't see anything in HJ's patch that does that. It uses priority, instead of MAX_INIT_PRIORITY - priority, to generate for .init_arry.. No, I was talking about order of constructors within a TU without using priority. If you have static constructors for A then B in your source file, gcc will output B's constructor before A's in the .ctors section, so that A's will run first. Where does your patch reverse that to account for the fact that .init_array sections are processed in forward order?
[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #56 from Cary Coutant ccoutant at gcc dot gnu.org 2010-12-14 01:24:30 UTC --- H.J, Cary is talking about multiple global constructors in a single file, none of which use constructor priorities. In other words, the normal case. gcc generates those in a specific required order for the .ctors section. If it does not reverse the order for .init_array, I don't see how it could possible work correctly. Again: a single file, no priorities specified. Right. I looked deeper and now see that gcc generates a single function per CU that runs all the static constructors for that CU, then adds that single entry to the .ctors section. So my concern was groundless -- the order of constructors within the CU is controlled by the code in that one function. -cary
[Bug lto/46291] [4.6 Regression] Failed to bootstrap-lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46291 --- Comment #4 from Cary Coutant ccoutant at gcc dot gnu.org 2010-11-03 21:31:22 UTC --- Sorry, the original design was for the plugin to maintain responsibility for the file descriptor. That didn't work well, so we added the GET_INPUT_FILE and RELEASE_INPUT_FILE interfaces to give that responsibility back to the linker. The text under Input Files is old and should have been changed to reflect the new design. I've updated the wiki. -cary
