https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
--- Comment #21 from Xi Ruoyao <xry111 at mengyan1223 dot wang> --- (In reply to Richard Biener from comment #20) > Indeed already the name, .LTHUNK5.lto_priv.0, hints at that this should be a > local symbol. Not sure why we end up with a .reloc then. > > ld $25,%got_disp(.LTHUNK5.lto_priv.0)($28) > .LEHB26 = . > .reloc 1f,R_MIPS_JALR,.LTHUNK5.lto_priv.0 > 1: jalr $25 > > this seems to be in _ZN4Sass6Parser16parse_parametersEv > > Maybe it's possible to reduce the testcase by bisecting the object files > necessary to produce the bogus LTRANS assembly? From that one can start > reducing the source of the necessary object files. > > Another interesting bit would be to see the IPA dumps of the broken LTRANS > unit. If you add -fdump-ipa-all-details to the link command you should get > dump files alongside the ltrans temp files. I can confirm that the workaround in gas (released in binutils-2.36) "fixes" the problem. Some function aliases named ".LTHUNK%d" are created in C++ FE (cp/method.c, L232). With LTO those are cloned as ".LTHUNK%d.lto_priv.%d". Functions aliases should not be named ".xxx" IMO. Perhaps names like __gcc_lthunk.%d is better.
