This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]