On Tue, Oct 20, 2015 at 4:37 PM, Bernd Schmidt <bschm...@redhat.com> wrote: > On 10/15/2015 12:37 PM, H.J. Lu wrote: >> >> On Thu, Oct 15, 2015 at 1:44 AM, Richard Biener >> <richard.guent...@gmail.com> wrote: >>> >>> On Wed, Oct 14, 2015 at 6:21 PM, H.J. Lu <hongjiu...@intel.com> wrote: >>>> >>>> By default, there is no visibility on builtin functions. When there is >>>> explicitly declared visibility on the C library function which a builtin >>>> function fall back on, we should honor the explicit visibility on the >>>> the C library function. > > >>> Doesn't the C++ FE have the same issue? >>> >> >> Unlike gcc, visibility triggers a warning in g++: >> >> memcpy.i:2:14: warning: ‘void* memcpy(void*, const void*, size_t)’: >> visibility attribute ignored because it conflicts with previous >> declaration [-Wattributes] >> extern void *memcpy(void *dest, const void *src, size_t n) >> ^ >> <built-in>: note: previous declaration of ‘void* memcpy(void*, const >> void*, size_t)’ >> [hjl@gnu-tools-1 pr67220]$ > > > I see no good reason for C and C++ to have different behaviour here. It > looks like the C++ frontend sets DECL_VISIBILITY_SPECIFIED to 1 for > builtins, causing the above behaviour. Cc'ing Jason, but I think the C++ > frontend should be changed not to set D_V_S and have the same changes as the > C frontend for merging the visibilities. > > Other than that I don't see a problem with the concept. However, I also > agree that the tests should not be i386 specific.
Sure. Just add target-specific scan-assembler-not. > One final question - it would seem that glibc is currently not affected by > this problem (at least I'm not seeing memcpy@plt calls in the binary on my > system), so how come this has become an issue now? > > R_386_PLT32 only shows in .o files. There are many of them in libc_pic.os. -- H.J.
