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 09/20/2017 10:38 AM, Steve Ellcey wrote:
On Wed, 2017-09-20 at 10:17 -0600, Martin Sebor wrote:

The comment copied below from sysdeps/aarch64/multiarch/memmove.c
suggests this might be deliberate:

/* Redefine memmove so that the compiler won't complain about the
type
    mismatch with the IFUNC selector in strong_alias, below.  */

so my guess is that the improved type checking has just exposed
this mismatch.  Can you please post the translation unit so we
can confirm it?

Thanks
Martin

The translation unit is sysdeps/aarch64/multiarch/memmove.c.  If I
preprocess that and cut out the unneeded parts I get:

extern int i;
typedef long unsigned int size_t;
extern void *__redirect_memmove (void *__dest, const void *__src,
size_t __n)
     __attribute__ ((__nothrow__ )) ;
extern __typeof (__redirect_memmove) __libc_memmove;
extern __typeof (__redirect_memmove) __memmove_generic ;
extern __typeof (__redirect_memmove) __memmove_thunderx ;
extern __typeof (__libc_memmove) __libc_memmove;
__typeof (__libc_memmove) *__libc_memmove_ifunc (void) __asm__
("__libc_memmove");
__attribute__ ((__optimize__ ("-fno-stack-protector"))) __typeof
(__libc_memmove) *__libc_memmove_ifunc (void)
        {
                __typeof (__libc_memmove) *res = i ? __memmove_thunderx
: __memmove_generic; return res; }

__asm__ (".type " "__libc_memmove" ", %gnu_indirect_function");
extern __typeof (__libc_memmove) memmove __attribute__ ((alias
("__libc_memmove")));;


Which, when compiled gives me:


% install/bin/gcc -c x.c
x.c:15:34: warning: ‘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)}’ [-Wattributes]
 extern __typeof (__libc_memmove) memmove __attribute__ ((alias
("__libc_memmove")));;
                                  ^~~~~~~
x.c:10:84: note: aliased declaration here
 (__optimize__ ("-fno-stack-protector"))) __typeof (__libc_memmove)
*__libc_memmove_ifunc (void)
                                                                     ^~
~~~~~~~~~~~~~~~~~~

Thanks.  I think the warning is working correctly, but I'm not
sure I completely understand the circuitous definitions or how
they are supposed to work.  They do appear to play tricks that
aren't type safe.

It looks to me like the file declares the __libc_memmove symbol
to have the same type as memmove.  It then defines the
__libc_memmove_ifunc function as an ifunc resolver for memmove
(i.e., a function that returns a pointer to memmove).  But it
also defines __libc_memmove as an alias for __libc_memmove_ifunc
and then memmove as an alias for the redefined __libc_memmove
with __libc_memmove_ifunc's type, and that's what GCC sees and
complains about.

I'm not intimately familiar with the Glibc ifunc infrastructure
to suggest a good solution here, so assuming this works my only
idea is to suppress the warning for these builds.

Joseph, do you have a better suggestion?

Martin


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