[Bug lto/126841] [LTO] -ffunction-sections can emit multiple distinct functions into one native section

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126841

--- Comment #7 from Longjun Luo <luolongjuna at gmail dot com> ---
Thanks.  I investigated this further and confirmed the root cause.

IPA-ICF turns two of the functions into address-preserving wrappers during
WPA.  While creating those wrappers, expand_thunk calls
resolve_unique_section, which resolves their implicit function-section
names from the pre-privatization assembler name, producing .text.same_fn.
LTO subsequently renames the symbols to same_fn.lto_priv.N in
privatize_symbol_name_1, but the already resolved section names are
retained.  The non-wrapper function reaches LTRANS without a resolved
section and therefore gets the expected .text.same_fn.lto_priv.0 name.

The implicit/explicit distinction needed for a narrowly scoped fix already
exists: resolve_unique_section records it in symtab_node::implicit_section
for the node and its aliases, and that flag is streamed with the symbol
table.  A small fix is therefore to clear only implicit section names after
LTO privatizes an assembler name, including those on aliases.  They are
then regenerated from the final assembler name, while explicit
user-specified section names are left unchanged.

For the first testcase this produces:

  .text.same_fn.lto_priv.2

The second testcase in comment #5 is fixed as well: the exported function
keeps .text.same_fn, while the two privatized functions get suffixed
section names, so they no longer share a section.

For the collision reported here—same-named local functions combined by
LTO—an additional filename-based naming scheme therefore does not appear
necessary.  The existing lto_priv suffix already provides the required
disambiguation.

The prototype patch includes a three-TU regression test and a documentation
clarification that LTO may add a compiler-generated suffix to distinguish
same-named internal-linkage items.  The test has two scan failures without
the change and passes completely with it.  The complete gcc.dg/lto and
g++.dg/lto test suites have no unexpected results.

I am preparing the patch for gcc-patches.