This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Builtins and C++ and such
- From: Roger Sayle <roger at eyesopen dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: Jason Merrill <jason at redhat dot com>, "jsm28 at cam dot ac dot uk" <jsm28 at cam dot ac dot uk>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, "bkoz at redhat dot com" <bkoz at redhat dot com>
- Date: Tue, 19 Mar 2002 17:10:44 -0700 (MST)
- Subject: Re: Builtins and C++ and such
> 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