https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101726
--- Comment #2 from Stefan Kneifel <stefan.kneifel at bluewin dot ch> ---
OK, so declaring the default function as local might make gcc assume that the
function body is available in the same translation unit, thus rendering the
relocation locally resolvable.
Thus said, I tried to apply the following patch:
---------------------------------------------------------
diff -ruN a/gcc/multiple_target.c b/gcc/multiple_target.c
--- a/gcc/multiple_target.c 2021-07-28 11:09:49.000000000 +0200
+++ b/gcc/multiple_target.c 2021-08-03 14:45:00.341857265 +0200
@@ -172,7 +172,6 @@
/* FIXME: copy of cgraph_node::make_local that should be cleaned up
in next stage1. */
- node->make_decl_local ();
node->set_section (NULL);
node->set_comdat_group (NULL);
node->externally_visible = false;
---------------------------------------------------------
and it seems to fix the problem (disassembler output of test case):
---------------------------------------------------------
test.o: file format elf64-x86-64
Disassembly of section .text:
0000000000000000 <_Z3barv>:
0: e9 00 00 00 00 jmpq 5 <_Z3barv+0x5>
1: R_X86_64_PLT32 _Z3foov-0x4
Disassembly of section .text._Z3foov.resolver:
0000000000000000 <_Z3foov.resolver>:
0: 51 push %rcx
1: e8 00 00 00 00 callq 6 <_Z3foov.resolver+0x6>
2: R_X86_64_PLT32 __cpu_indicator_init-0x4
6: 48 8b 05 00 00 00 00 mov 0x0(%rip),%rax # d
<_Z3foov.resolver+0xd>
9: R_X86_64_REX_GOTPCRELX __cpu_model-0x4
d: 8b 40 0c mov 0xc(%rax),%eax
10: 0f ba e0 0f bt $0xf,%eax
14: 73 09 jae 1f <_Z3foov.resolver+0x1f>
16: 48 8b 05 00 00 00 00 mov 0x0(%rip),%rax # 1d
<_Z3foov.resolver+0x1d>
19: R_X86_64_REX_GOTPCRELX _Z3foov.avx512f.0-0x4
1d: eb 25 jmp 44 <_Z3foov.resolver+0x44>
1f: 0f ba e0 0a bt $0xa,%eax
23: 73 09 jae 2e <_Z3foov.resolver+0x2e>
25: 48 8b 05 00 00 00 00 mov 0x0(%rip),%rax # 2c
<_Z3foov.resolver+0x2c>
28: R_X86_64_REX_GOTPCRELX _Z3foov.avx2.1-0x4
2c: eb 16 jmp 44 <_Z3foov.resolver+0x44>
2e: 0f ba e0 09 bt $0x9,%eax
32: 73 09 jae 3d <_Z3foov.resolver+0x3d>
34: 48 8b 05 00 00 00 00 mov 0x0(%rip),%rax # 3b
<_Z3foov.resolver+0x3b>
37: R_X86_64_REX_GOTPCRELX _Z3foov.avx.2-0x4
3b: eb 07 jmp 44 <_Z3foov.resolver+0x44>
3d: 48 8b 05 00 00 00 00 mov 0x0(%rip),%rax # 44
<_Z3foov.resolver+0x44>
40: R_X86_64_REX_GOTPCRELX _Z3foov.default.3-0x4
44: 5a pop %rdx
45: c3 retq
---------------------------------------------------------
However, as a total GCC greenhorn I'm absolutely not sure of any side effects
that could be introduced by this hack ;-) so please Martin check that
thoroughly, if it shouldn't be fixed in a more sophisticated way. It might
revert the "Bug 81238" patch. Thank you very much!
