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. The other thing looks like sth for next stage1? Thanks, Richard. > Martin > > > > > Richard. > > > >> > >> -- > >> H.J. >
