On 1/23/20 2:09 PM, Richard Biener wrote:
On Tue, Jan 21, 2020 at 1:48 PM Martin Liška <mli...@suse.cz> wrote:
On 1/20/20 3:52 PM, Richard Biener wrote:
On Mon, Jan 20, 2020 at 3:46 PM H.J. Lu <hjl.to...@gmail.com> wrote:
On Mon, Jan 20, 2020 at 6:41 AM Alexander Monakov <amona...@ispras.ru> wrote:
On Mon, 20 Jan 2020, H.J. Lu wrote:
Bare IFUNC's don't seem to have this restriction. Why do we want to
constrain target clones this way?
foo's resolver acts as foo. It should have the same visibility as foo.
What do you mean by that? From the implementation standpoint, there's
two symbols of different type with the same value. There's no problem
allowing one of them have local binding and the other have global binding.
Is there something special about target clones that doesn't come into
play with ifuncs?
I stand corrected. Resolver should be static and it shouldn't be weak.
Reading the patch again and looking up more context it seems that the resolver
is already static we just mangle it extra when the original function
is public (?)
If so the patch looks quite obvious to me if we use some character not valid
in indetifiers in C but valid in assembly for the resolver decl.
Hello.
I'm sending updated version of the patch where I'm adding a run-time test
for 2 static symbols (with the same name) and it works fine. Moreover
I'm newly setting TREE_PUBLIC (ifunc_alias_decl) = 0 which seems to
work properly.
I tested both x86_64-linux-gnu and ppc64le-linux-gnu.
So this doesn't help review including two different target changes. Making
ifunc dispatchers of public functions non-public looks like an unrelated thing
to the bug (sorry if I mis-suggested). So I feel comfortable approving the
earlier patch which just dropped the extra mangling for non-public dispatchers
in the x86 backend.
Works for me.
The other thing looks like sth for next stage1?
Yes.
Martin
Thanks,
Richard.
Martin
Richard.
--
H.J.
