http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46559
--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-11-26
15:09:34 UTC ---
The FAILs also occur with -flto-partition=none.
Hm, looking at 27_io/basic_filebuf/underflow/10096.cc there are no location
lists at all in the LTO assembler:
.section .debug_loc,"",@progbits
.Ldebug_loc0:
dwarf2out.c:output_loc_list is never called, add_AT_loc_list is, so is
output_location_lists.
But the local var 'die' that is refered is the last in the limbo_die_list.
Do we expect this magically to be comp_unit_die? For the testcase
in question it is a DW_TAG_structure_type. With multiple comp-unit dies
as we now can have with LTO do we need to iterate through them for
the remaining parts of dwarf2out after limbo-die processing?
Well.
Index: dwarf2out.c
===================================================================
--- dwarf2out.c (revision 167177)
+++ dwarf2out.c (working copy)
@@ -23177,7 +23176,7 @@ dwarf2out_finish (const char *filename)
add_AT_macptr (comp_unit_die (), DW_AT_macro_info, macinfo_section_label);
if (have_location_lists)
- optimize_location_lists (die);
+ optimize_location_lists (comp_unit_die ());
/* Output all of the compilation units. We put the main one last so that
the offsets are available to output_pubnames. */
@@ -23222,7 +23221,7 @@ dwarf2out_finish (const char *filename)
ASM_GENERATE_INTERNAL_LABEL (loc_section_label,
DEBUG_LOC_SECTION_LABEL, 0);
ASM_OUTPUT_LABEL (asm_out_file, loc_section_label);
- output_location_lists (die);
+ output_location_lists (comp_unit_die ());
}
/* Output public names table if necessary. */
fixes this bug and makes sense anyway.
