https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77894
Bug ID: 77894 Summary: Enable GNU indirect function support by default as it will be used in glibc. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: stli at linux dot vnet.ibm.com Target Milestone: --- Starting with glibc-commits "Add configure check to test if gcc supports attribute ifunc." (https://sourceware.org/git/?p=glibc.git;a=commit;h=022dfdce000374b60aadfb0a5ed9a5c4c1dbd29b), "Use gcc attribute ifunc in libc_ifunc macro instead of inline assembly due to false... " (https://sourceware.org/git/?p=glibc.git;a=commit;h=00980d845f8f2ec3ed4ad161a1e5b97704be1929) and further, for glibc with multi-arch support it is recommended to use a GCC which has been built with support for GNU indirect functions. This ensures that correct debugging information is generated for functions selected by IFUNC resolvers. This support can either be enabled by configuring GCC with '--enable-gnu-indirect-function', or by enabling it by default by setting 'default_gnu_indirect_function' variable for a particular architecture in the GCC source file 'gcc/config.gcc'. Currently GNU indirect function support is only enabled by default for few configurations like intel and s390. Please enable it by default for other architectures, too. E.g. according to the rpm-spec file fedora/rhel is configuring gcc with --enable-gnu-indirect-function for the following architectures: %{ix86} x86_64 ppc ppc64 ppc64le ppc64p7 s390 s390x %{arm} aarch64. Perhaps a configure check could test the presence of the non-standard gnu ifunc support in the assembler, linker and dynamic linker and could automatically dis/enable the support. But this behaviour should be discussed by the gcc maintainers.