Re: C++: Difference between calling memcpy and __builtin_memcpy

[Florian Weimer <fweimer at redhat dot com>]

On 03/14/2016 05:52 PM, Martin Sebor wrote:
>> The only reason not to do this is that the address of the strchr
>> function will not be consistent across the entire process.  Do you think
>> this could be a problem, even just a conformance problem?
> 
> I'm not sure I understand the concern.  There can be up to three
> overloads of strchr in a program (one extern "C" and two extern
> "C++" if the program includes C++ bits).  Each of the overloads
> must has its own distinct address (and name) but that address of
> the same overload needs to be the same across the whole program
> (though the C bits will never see the C address and the C++ bits
> have no way of accessing the C address in conforming programs).
> As long as this invariant is maintained I don't think there is
> a problem.

I think I did my test with âstatic inlineâ.  In this case, each
translation unit gets its own out-of-line copy if the address of the
function is taken.

This does not happen with âinlineâ or âextern inlineâ; there is just a
single copy in this case.

I think this means it's an all-around improvement to replace the asm
aliases in glibc with inline function wrappers, as suggested here:

  https://sourceware.org/bugzilla/show_bug.cgi?id=19618

The inline wrappers help non-GCC compilers, and current GCC produces
better code because it will recognize strchr as such, which currently
does not happen due to the asm alias.

Thanks,
Florian