On Nov 8, 2023, Alexandre Oliva <ol...@adacore.com> wrote: > Ping?
Ping? https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635731.html The test still fails with gcc-14 and trunk on ia32 with -fPIE. I've just retested it on trunk on i686-linux-gnu with -fPIE, and on x86_64-linux-gnu. > gcc.target/i386/mvc10.c fails with -fPIE on ia32 because we omit the > @PLT mark when calling an alias to an indirect function. Such aliases > aren't marked as ifunc_resolvers in the cgraph, so the test that would > have forced the PLT call fails. > I've arranged for ifunc_resolver to be back-propagated to aliases, and > relaxed the test that required the ifunc attribute to be attached to > directly the decl, rather than taken from an aliased decl, when the > ifunc_resolver bit is set. > Regstrapped on x86_64-linux-gnu, also tested with gcc-13 on i686- and > x86_64-. Ok to install? > (in the initial patchset for PR83782 and mvc10, I also needed > https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598873.html but I'm > not getting that fail any more with gcc-13, apparently because a > different patch was put in to address that part) > for gcc/ChangeLog > PR target/83782 > * cgraph.h (symtab_node::set_ifunc_resolver): New, overloaded. > Back-propagate flag to aliases. > * cgraph.cc (cgraph_node::create): Use set_ifunc_resolver. > (cgraph_node::create_alias): Likewise. > * lto-cgraph.cc (input_node): Likewise. > * multiple_target.cc (create_dispatcher_calls): Propagate to > aliases when redirecting them. > * symtab.cc (symtab_node::verify_base): Accept ifunc_resolver > set in an alias to another ifunc_resolver nodes. > (symtab_node::resolve_alias): Propagate ifunc_resolver from > resolved target to alias. > * varasm.cc (do_assemble_alias): Checking for the attribute. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
