This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [PATCH] detect incompatible aliases (PR c/81854)
- From: Steve Ellcey <sellcey at cavium dot com>
- To: Martin Sebor <msebor at gmail dot com>, Joseph Myers <joseph at codesourcery dot com>
- Cc: Gcc Patch List <gcc-patches at gcc dot gnu dot org>, Jonathan Wakely <jwakely at redhat dot com>, libstdc++ <libstdc++ at gcc dot gnu dot org>
- Date: Wed, 20 Sep 2017 08:37:37 -0700
- Subject: Re: [PATCH] detect incompatible aliases (PR c/81854)
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Steve dot Ellcey at cavium dot com;
- References: <61673e8d-6f5c-9bc0-dcf8-75eee71f98de@gmail.com>
- Reply-to: sellcey at cavium dot com
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
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
In file included from <command-line>:0:0:
../sysdeps/aarch64/multiarch/memmove.c:38:31: error: ‘memmove’ alias
between functions of incompatible types ‘void *(void *, const void *,
size_t) {aka void *(void *, const void *, long unsigned int)}’ and
‘void * (*(void))(void *, const void *, size_t) {aka void *
(*(void))(void *, const void *, long unsigned int)}’ [-
Werror=attributes]
strong_alias (__libc_memmove, memmove);
^~~~~~~
./../include/libc-symbols.h:135:26: note: in definition of macro
‘_strong_alias’
extern __typeof (name) aliasname __attribute__ ((alias (#name)));
^~~~~~~~~
../sysdeps/aarch64/multiarch/memmove.c:38:1: note: in expansion of
macro ‘strong_alias’
strong_alias (__libc_memmove, memmove);
^~~~~~~~~~~~
In file included from <command-line>:0:0:
../sysdeps/aarch64/multiarch/memmove.c:34:13: note: aliased declaration
here
libc_ifunc (__libc_memmove,
^~~~~~~~~~~~~~
./../include/libc-symbols.h:800:25: note: in definition of macro
‘__ifunc_resolver’
__typeof (type_name) *name##_ifunc (arg) \
^~~~
./../include/libc-symbols.h:916:32: note: in expansion of macro
‘__ifunc’
#define libc_ifunc(name, expr) __ifunc (name, name, expr, void,
INIT_ARCH)
^~~~~~~
../sysdeps/aarch64/multiarch/memmove.c:34:1: note: in expansion of
macro ‘libc_ifunc’
libc_ifunc (__libc_memmove,
^~~~~~~~~~
cc1: all warnings being treated as errors