Re: __builtin_* expansion to outcalls vs name space issues

["Carlos O'Donell" <carlos at redhat dot com>]

On 02/05/2013 03:35 PM, Roland McGrath wrote:
> I happened to be looking at disassembly of elf/dl-hwcaps.o and noticed
> that it had calls to mempcpy.  That set off alarm bells since this is
> deep internals code that should never be using symbols outside the C89
> implementation name space, which mempcpy is.  Looking deeper, I found
> that all that source code is in fact properly calling __mempcpy as it
> should.
> 
> The issue arises because <bits/string2.h> defines __mempcpy as a macro
> using __builtin_mempcpy.  Then GCC decides not to inline these cases,
> and generates calls to mempcpy.  (Looking at the compiler, it seems like
> it might well treat mempcpy as __builtin_mempcpy too in -std=gnu99 mode.
> But it would never treat __mempcpy that way AFAIK.)
> 
> What should be the expectation of responsibility here?  On the one hand,
> it seems vaguely reasonable that __builtin_foobar degenerates to calling
> foobar.  On the other hand, it is surprising to me that the compiler
> should ever generate an implicit call to a symbol outside the most
> constrained implementation name space.  If my source code uses only
> symbols in a limited name space, then the compiler should not expand the
> scope of name space my code interacts with.
> 
> So, are we wrong for using __builtin_mempcpy in a place where a call to
> mempcpy is not kosher?  Or is GCC wrong for having __builtin_* ever
> generate a call to something outside the C89 implementation name space?
> 
> In either case, what do we do to fix it?  In the former, we'd have to
> give up some compiler-managed optimization opportunities and enforce a
> nonobvious discipline about referring to __builtin_*.  In the latter, we
> need to teach GCC to call __mempcpy instead, but is that going to cause
> any problems?

Can it be both our faults?

We should call __memcpy directly, and never __builtin_memcpy which can
and may degenerate to memcpy.

I don't think the compiler should call __memcpy, since this would change
the existing behaviour for applications that provide their own malloc.
That could break applications and we try to avoid that if possible.

Lastly the compiler should not allow __builtin_memcpy if it wouldn't
allow memcpy or alternatively __builtin_memcpy should never fall back 
to memcpy if memcpy is not allowed. This might break building your
application, but all you need to do is set the right flags and you're
OK to compile again.

Does that make sense?

Cheers,
Carlos.