https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50199
--- Comment #25 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 10 Jan 2017, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50199 > > --- Comment #24 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > Another option is to silently force -flto-partition=none (or would > -flto-partition=1to1 work too?) if !flag_merge_constants or HAVE_GAS_SHF_MERGE > is not defined. Or silently turn on flag_merge_constants (set to 1 if 0) in > lto compilation, and/or force -flto-partition=none (or 1to1) if > HAVE_GAS_SHF_MERGE is not defined. > Honza/Richard, what do you prefer here? I prefer handling constants correctly, forcing STRING_CSTs to only appear via CONST_DECL DECL_INITIAL and putting CONST_DECLs into a symbol-table like constant pool on the cgraph level. That's quite some work and the question is whether this bug is important enough to warrant a fix like you propose. Of your proposals I prefer forcing -fmerge-constants (and/or simply documenting the restriction of LTO when working w/o constant merging). At some point I started the &STRING_CST -> &CONST_DECL thing (I have partial patches somewhere) but there was some fallout I didn't fully address. The issue with LTO is that we fail to merge in-TU constants because we have those &STRING_CSTs and tear apart the TU. So - force flag_merge_constants to 1 if in_lto_p? Or do that from lto-wrapper, diagnosing that we do that?
