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

["H.J. Lu" <hjl dot tools at gmail dot 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.
>

What should we do with C++ front-end?

-- 
H.J.