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 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.
>>
>> There are 2 issues:
>>
>> 1. We never update visibility of the fall back C library function.
>> 2. init_block_move_fn and init_block_clear_fn used to implement builtin
>> memcpy and memset generate the library call to memcpy and memset
>> directly without checking if there is explicitly declared visibility on
>> them.
>>
>> This patch updates builtin function with explicit visibility and checks
>> visibility on builtin memcpy/memset when generating library call.
>>
>> Tested on Linux/x86-64 without regressions.  OK for trunk?
>
> Doesn't the C++ FE have the same issue?
>

Unlike gcc, visibility triggers a warning in g++:

[hjl@gnu-tools-1 pr67220]$ cat memcpy.i
typedef unsigned long size_t;
extern void *memcpy(void *dest, const void *src, size_t n)
  __attribute__ ((visibility ("hidden")));

void
bar (void *d, void *s, size_t n)
{
  memcpy (d, s, n);
}
[hjl@gnu-tools-1 pr67220]$ make memcpy.s
/export/build/gnu/gcc/build-x86_64-linux/gcc/xg++
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -fPIC -S memcpy.i
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]$

Since those fallback functions are in the C library, it is very
unlikely they can be hidden in C++.  They are mostly likely
to happen inside of the C library.

-- 
H.J.