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.
