[PATCH] detect incompatible aliases (PR c/81854)

[Martin Sebor]

On 10/02/2017 01:49 PM, Steve Ellcey wrote:
> On Wed, 2017-09-20 at 08:37 -0700, Steve Ellcey wrote:
>> On Tue, 2017-09-19 at 09:16 -0600, Martin Sebor wrote:
>>> On 09/18/2017 03:44 PM, Joseph Myers wrote:
>>>> On Mon, 18 Sep 2017, Martin Sebor wrote:
>>>>> It's meant as an escape hatch.  It allows declaring
>>>>> compatibility
>>>>> symbols, for example by the libstdc++ _GLIBCXX_3_4_SYMVER macro
>>>>> defined in libstdc++-v3/src/c++98/compatibility.cc.  The macro
>>>>> is
>>>>> used to declare compatibility functions of all sorts of
>>>>> incompatible
>>>>> types.  The originally posted patch had libstdc++ disable the
>>>>> warning
>>>>> for the file with the symbols but Jonathan preferred this
>>>>> solution.
>>>>>
>>>>> It could perhaps be tightened up to detect some of the cases on
>>>>> your
>>>>> list but I'm not sure it's worth the effort and added
>>>>> complexity.
>>>>> Let me know if you feel differently (or have a different
>>>>> suggestion),
>>>>> otherwise I will go ahead and commit the patch as is.
>>>> Please add a comment explaining this reasoning and commit the
>>>> patch.
>>> Done in r252976.
>>>
>>> Thanks
>>> Martin
>> This patch is causing my gcc/glibc ToT build to fail on aarch64.  I am
>> not sure if everything should be working at this point or not or if
>> there is more that needs to be done.  The problem is with the memcpy,
>> memmove, etc. ifuncs on aarch64.
>>
>> Steve Ellcey
>> sellcey@cavium.com
>
> Martin,
>
> I think there is more fallout from this patch.  The libatomic library
> can use ifuncs and right now it is not working on aarch64 (testing a
> proposed patch I sent) because the ifunc check fails due to the new
> warnings.  I believe this can be reproduced with ToT on x86 or arm as
> they use ifuncs in the checked in sources but I have not tried that
> yet.  Note that the build does not fail, it is just that the check for
> ifunc support fails and thus the library is built without them.
>
> Steve Ellcey
> sellcey@cavium.com
>
> configure:14698: checking whether the target supports the ifunc attribute
> configure:14720: /home/sellcey/gcc-libatomic/obj/gcc/./gcc/xgcc
> -B/home/sellcey/gcc-libatomic/obj/gcc/./gcc/ -B/home/sellcey/gcc-
> libatomic/install/aarch64-unknown-linux-gnu/bin/ -B/home/sellcey/gcc-
> libatomic/install/aarch64-unknown-linux-gnu/lib/ -isystem
> /home/sellcey/gcc-libatomic/install/aarch64-unknown-linux-gnu/include
> -isystem /home/sellcey/gcc-libatomic/install/aarch64-unknown-linux-
> gnu/sys-include    -o conftest -g -O2  -pthread
> -Werror   conftest.c  >&5
> conftest.c:68:9: error: 'foo' 'ifunc' resolver should return a function
> pointer [-Werror=attributes]
>      int foo(void) __attribute__((ifunc("foo_sel")));
>          ^~~
> conftest.c:67:11: note: resolver declaration here
>      void *foo_sel(void) { return foo_alt; }
>            ^~~~~~~
> cc1: all warnings being treated as errors
> configure:14720: $? = 1

Looks like the libatomic/configure script needs to be updated
to have the ifunc test either declare the resolver to return
a function pointer or avoid using -Werror.  I assume the below
is the preferred fix but I need to get the right version of
autoconf etc. to regenerate configure.  Let me work on that
and submit a patch.

Martin

diff --git a/libatomic/acinclude.m4 b/libatomic/acinclude.m4
index 485d731..383218f 100644
--- a/libatomic/acinclude.m4
+++ b/libatomic/acinclude.m4
@@ -195,7 +195,8 @@ AC_DEFUN([LIBAT_CHECK_IFUNC], [
    CFLAGS="$CFLAGS -Werror"
    AC_TRY_LINK([
      int foo_alt(void) { return 0; }
-    void *foo_sel(void) { return foo_alt; }
+    typedef int F (void);
+    F *foo_sel(void) { return foo_alt; }
      int foo(void) __attribute__((ifunc("foo_sel")));],
      [return foo();], libat_cv_have_ifunc=yes, libat_cv_have_ifunc=no)])
    LIBAT_DEFINE_YESNO([HAVE_IFUNC], [$libat_cv_have_ifunc],


Martin