Builtins and C++ and such

[Roger Sayle]

> Why?  (Not meant to be a rhetorical question; I'm curious.)
>
> Certainly, __builtin_memcpy is necessary -- but why gunk to turn
> memcpy into __builtin_memcpy?  Isn't that something the library
> headers can do for you, at least in C++ where you *had* to have
> a declaration?  Do we really care about people who manually write
> the declaration themselves?

Amongst the issues that I hope would be fixed by the solution that
we decide upon is the ISO C++ requirement that #include <string.h>
defines both "::memcpy" and "std::memcpy" (i.e. in both the std and
global namespaces).  This is apparently a "known" issue with gcc, and
the current method of including the system's native C headers (albeit
fixincluded) doesn't allow much scope for tweaking.

I've been investigating a scheme whereby a user declaration in a system
header that "matches" an anticipated built-in, introduces that built-in
definition into both namespaces.  If it worked, it might make things
easier for the libstdc++ folks, rather than shadow /usr/include.

Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833