https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69393
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |NEW
CC| |hubicka at gcc dot gnu.org,
| |jakub at gcc dot gnu.org
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ok, I can reproduce the ICE.
(gdb) p deferred_asm_name->created_for
$4 = (tree) 0x7ffff64fc980
(gdb) p debug_generic_expr ($4)
.omp_data_s.34
aha and that's indeed a TYPE_DECL which is DECL_ARTIFICIAL but ! DECL_IGNORED.
Jakub - is debug info intended for this TYPE_DECL? Honza, do the TYPE_DECL
asm-names make sense here?
/* This is a GNU Extension. We are adding a
DW_AT_linkage_name attribute to the DIE of the
anonymous struct TYPE. The value of that attribute
is the name of the typedef decl naming the anonymous
struct. This greatly eases the work of consumers of
this debug info. */
add_linkage_name_raw (lookup_type_die (type), decl);
(gdb) p debug_tree ($4)
<type_decl 0x7ffff64fc980 .omp_data_s.34
type <record_type 0x7ffff64fad20 .omp_data_s.34 asm_written BLK
size <integer_cst 0x7ffff688bf18 constant 256>
unit size <integer_cst 0x7ffff68a8018 constant 32>
align 64 symtab -162595952 alias set 77 canonical type 0x7ffff64fad20
fields <field_decl 0x7ffff64fc8e8 P type <pointer_type 0x7ffff682f930>
unsigned DI file STAR.cpp line 56 col 17
size <integer_cst 0x7ffff688bbb8 constant 64>
unit size <integer_cst 0x7ffff688bbd0 constant 8>
align 64 offset_align 128
offset <integer_cst 0x7ffff688bbe8 constant 0>
bit offset <integer_cst 0x7ffff688bc30 constant 0> context
<record_type 0x7ffff64fad20 .omp_data_s.34> chain <field_decl 0x7ffff64fc850
totalMem>>
pointer_to_this <pointer_type 0x7ffff6511888>>
asm_written VOID file STAR.cpp line 353 col 9
align 1>
That said - we either need to make sure to compute and stream
DECL_ASSEMBLER_NAME for the above or avoid emitting late debug for this
(for example via adjusting is_naming_typedef_decl).
Note that it looks like free-lang-data misses to traverse
fn->static_chain_decl,
but fixing that doesn't fix this PR.
The DWARF for the above decl is created via
#4 0x00000000008bfadc in dwarf2out_type_decl (decl=0x7ffff64fc980, local=0)
at /space/rguenther/src/svn/trunk3/gcc/dwarf2out.c:23536
#5 0x000000000076535f in lto_read_decls (decl_data=0x7ffff7fed000,
data=0x7ffff7ef3a00, resolutions=...)
at /space/rguenther/src/svn/trunk3/gcc/lto/lto.c:1761
So back to why this hasn't been assigned an assembler name in free-lang-data.
FLD has
static inline bool
need_assembler_name_p (tree decl)
{
...
if (flag_lto_odr_type_mering
&& TREE_CODE (decl) == TYPE_DECL
&& DECL_NAME (decl)
&& decl == TYPE_NAME (TREE_TYPE (decl))
&& !TYPE_ARTIFICIAL (TREE_TYPE (decl))
&& (type_with_linkage_p (TREE_TYPE (decl))
|| TREE_CODE (TREE_TYPE (decl)) == INTEGER_TYPE)
&& !variably_modified_type_p (TREE_TYPE (decl), NULL_TREE))
return !DECL_ASSEMBLER_NAME_SET_P (decl);
/* Only FUNCTION_DECLs and VAR_DECLs are considered. */
if (TREE_CODE (decl) != FUNCTION_DECL
&& TREE_CODE (decl) != VAR_DECL)
return false;
but TYPE_ARTIFICIAL (TREE_TYPE (decl)) is true. Guarding the above with
flag_lto_odr_type_merging also looks suspicious - seems the code doesn't
consider debug info for TYPE_DECLs at all?
dwarf2out guards the assembler-name use with
if (DECL_ORIGINAL_TYPE (decl))
...
else
{
type = TREE_TYPE (decl);
...
if (is_naming_typedef_decl (TYPE_NAME (type)))
{
it seems to me we can't really use debug_info_level at compile-time
to guard things here so we'd have to unconditionally assign
assembler names to TYPE_DECLs under the above condition?
Or arrange so that is_naming_typedef_decl doesn't apply to those artificial
OMP type-decls? (why do we have type-decls for this at all...?)
