http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #27 from rguenther at suse dot de <rguenther at suse dot de> 2013-03-05 13:58:15 UTC --- On Tue, 5 Mar 2013, ebotcazou at gcc dot gnu.org wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494 > > --- Comment #26 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2013-03-05 > 13:51:28 UTC --- > > The question is why we don't hit lto-lang.c:lto_set_decl_assembler_name > > mangling of !TREE_PUBLIC decls when streaming in the decl for the constant > > pool entries (or when computing the assembler name at some point). > > I suppose we never compute decl-assembler-name for the constant pool entries > > but emit them in a special way? > > Right, see make_decl_rtl: > > /* If this variable belongs to the global constant pool, retrieve the > pre-computed RTL or recompute it in LTO mode. */ > if (TREE_CODE (decl) == VAR_DECL && DECL_IN_CONSTANT_POOL (decl)) > { > SET_DECL_RTL (decl, output_constant_def_1 (DECL_INITIAL (decl), > decl, 1)); > return; > } > > > At least build_constant_desc seems to create a raw SYMBOL_RER using the raw > > created label? But then, as we don't stream the constant-descs, the RTL > > should refer to unique labels (but DECL_NAME and the SYMBOL_REF symbol do > > not > > agree). > > I think the problem is that, with your patch, the DECLs are not unified when > they have the same DECL_INITIAL (decl), even if they have the same RTL in the > end. Hmm, but when I use the same contents for the two arrays in my simple testcase I do get only a single .LC0 output referenced from two places. We will end up sharing the same RTL for both (unmerged) DECLs - but I don't see how this can be a problem? Maybe we fail to set TREE_ASM_WRITTEN on the duplicate and output it anyway via other mechanisms? But I can reproduce the Ada LTO bootstrap failure ...
