[Bug c/101726] New: target_clone resolver does not generate PIC despite -fPIC

[Bug c/101726] New: target_clone resolver does not generate PIC despite -fPIC

[stefan.kneifel at bluewin dot ch]

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

            Bug ID: 101726
           Summary: target_clone resolver does not generate PIC despite
                    -fPIC
           Product: gcc
           Version: 11.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: stefan.kneifel at bluewin dot ch
  Target Milestone: ---

Created attachment 51243
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51243&action=edit
Testcase: compile with -Os -fPIC

When compiling code using target_clones with -fPIC, the automatically generated
resolver refers to all the explicit targets correctly using
R_X86_64_REX_GOTPCRELX, whereas it refers to the default target incorrectly
using R_X86_64_PC32, resulting in an object file not linkable into a shared
library.

Compile the attached test.ii with:
gcc -Os -pipe -fPIC -c test.ii

and disassemble the output with:
objdump -rd test.o

--------------------------------------------
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 50 0c                mov    0xc(%rax),%edx
  10:   0f ba e2 0f             bt     $0xf,%edx
  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 23                   jmp    42 <_Z3foov.resolver+0x42>
  1f:   0f ba e2 0a             bt     $0xa,%edx
  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 14                   jmp    42 <_Z3foov.resolver+0x42>
  2e:   0f ba e2 09             bt     $0x9,%edx
  32:   48 8d 05 00 00 00 00    lea    0x0(%rip),%rax        # 39
<_Z3foov.resolver+0x39>
                        35: R_X86_64_PC32       _Z3foov.default.3-0x4
  39:   73 07                   jae    42 <_Z3foov.resolver+0x42>
  3b:   48 8b 05 00 00 00 00    mov    0x0(%rip),%rax        # 42
<_Z3foov.resolver+0x42>
                        3e: R_X86_64_REX_GOTPCRELX      _Z3foov.avx.2-0x4
  42:   5a                      pop    %rdx
  43:   c3                      retq   
--------------------------------------------

This should be consistent, and _Z3foov.default.3 should also be read from the
GOT.

[Bug target/101726] target_clone resolver does not generate PIC despite -fPIC

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org,
                   |                            |meissner at linux dot vnet.ibm.com
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |marxin at gcc dot gnu.org
   Last reconfirmed|                            |2021-08-03

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Confirmed, started with r8-1671-g926c786507a69f31. I'm going to take a look.

[Bug target/101726] target_clone resolver does not generate PIC despite -fPIC

[stefan.kneifel at bluewin dot ch]

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!

[Bug target/101726] target_clone resolver does not generate PIC despite -fPIC

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
So the solution won't be so easy. We generally face the problem that:
void    foo     (void)          __attribute__  
((target_clones("avx512f,avx2,avx,default")));

is only a declaration. If we consider another TU with:

void
__attribute__   ((target_clones("avx512f,avx2,avx,default")))
foo     (void)
{
}

we end up with:

/tmp/cc5grfLD.o:pr101726.c:foo: error: undefined reference to 'foo.avx512f.0'
/tmp/cc5grfLD.o:pr101726.c:foo: error: undefined reference to 'foo.avx2.1'
/tmp/cc5grfLD.o:pr101726.c:foo: error: undefined reference to 'foo.avx.2'
/tmp/cc5grfLD.o:pr101726.c:foo: error: undefined reference to 'foo.default.3'

anyway. That's caused by the fact that target_clones are made local and so the
references are unresolved.
My suggestion would be simply doing a normal declaration:
void foo(void);

and doing target_clone definition in another TU. Doing that works would work.
That said, we should likely forbid target_clone declarations. Or do I miss
something?

[Bug target/101726] target_clone resolver does not generate PIC despite -fPIC

[stefan.kneifel at bluewin dot ch]

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

--- Comment #4 from Stefan Kneifel <stefan.kneifel at bluewin dot ch> ---
Yes, but a programmer might choose to implement target clones for a shared
library using another language, e.g. hand-optimized assembler code (this was
the actual problem I had).

Forbidding target_clone declarations would make that solution impossible, which
should IMHO not be the case. To my opinion, the original solution (if the
target_clone function declaration is public, then it should be regarded as
public) is the most consequent one.

[Bug target/101726] target_clone resolver does not generate PIC despite -fPIC

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Stefan Kneifel from comment #4)
> Yes, but a programmer might choose to implement target clones for a shared
> library using another language, e.g. hand-optimized assembler code (this was
> the actual problem I had).

Ah, I hadn't thought about such a use case.

> Forbidding target_clone declarations would make that solution impossible,
> which should IMHO not be the case. To my opinion, the original solution (if
> the target_clone function declaration is public, then it should be regarded
> as public) is the most consequent one.

All right, I'm going to send such a patch.

[Bug ipa/101726] target_clone resolver does not generate PIC despite -fPIC

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch

--- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> ---
I've just sent a patch to ML:
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577287.html

[Bug ipa/101726] target_clone resolver does not generate PIC despite -fPIC

[stefan.kneifel at bluewin dot ch]

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

--- Comment #7 from Stefan Kneifel <stefan.kneifel at bluewin dot ch> ---
OK works for me, thank you!

[Bug ipa/101726] target_clone resolver does not generate PIC despite -fPIC

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Martin Liska <marxin@gcc.gnu.org>:

https://gcc.gnu.org/g:91292490d573f9f9e4f162d6d8c693a969197f2d

commit r12-2921-g91292490d573f9f9e4f162d6d8c693a969197f2d
Author: Martin Liska <mliska@suse.cz>
Date:   Thu Aug 12 16:01:01 2021 +0200

    ipa: make target_clone default decl local [PR101726]

            PR ipa/101726

    gcc/ChangeLog:

            * multiple_target.c (create_dispatcher_calls): Make default
              function local only if it is a definition.

[Bug ipa/101726] target_clone resolver does not generate PIC despite -fPIC

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |12.0

--- Comment #9 from Martin Liška <marxin at gcc dot gnu.org> ---
Fixed on master so far.

[Bug ipa/101726] target_clone resolver does not generate PIC despite -fPIC

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Martin Liska
<marxin@gcc.gnu.org>:

https://gcc.gnu.org/g:3d520d00ac688166f9dc4a24ad7d1ddfd686b03d

commit r11-8868-g3d520d00ac688166f9dc4a24ad7d1ddfd686b03d
Author: Martin Liska <mliska@suse.cz>
Date:   Thu Aug 12 16:01:01 2021 +0200

    ipa: make target_clone default decl local [PR101726]

            PR ipa/101726

    gcc/ChangeLog:

            * multiple_target.c (create_dispatcher_calls): Make default
              function local only if it is a definition.

[Bug ipa/101726] target_clone resolver does not generate PIC despite -fPIC

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |11.2.1
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #11 from Martin Liška <marxin at gcc dot gnu.org> ---
Fixed in gcc-11 branch, I'm not planning backporting that more.