__builtin_* expansion to outcalls vs name space issues

[Roland McGrath <roland at hack dot frob dot com>]

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?


Thanks,
Roland