Re: [PATCH] PR middle-end/67220: GCC fails to properly handle libcall symbol visibility of built functions

[Bernd Schmidt <bschmidt@redhat.com>]

On 10/15/2015 12:37 PM, H.J. Lu wrote:
> On Thu, Oct 15, 2015 at 1:44 AM, Richard Biener
> <richard.guenther@gmail.com> wrote:
>> On Wed, Oct 14, 2015 at 6:21 PM, H.J. Lu <hongjiu.lu@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.

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?


Bernd