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

["H.J. Lu" <hjl.tools@gmail.com>]

On Tue, Oct 20, 2015 at 4:37 PM, Bernd Schmidt <bschmidt@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.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.

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.