This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Builtins and C++ and such (take 2)
- From: Fergus Henderson <fjh at cs dot mu dot oz dot au>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: Mark Mitchell <mark at codesourcery dot com>,Benjamin Kosnik <bkoz at redhat dot com>,Alexandre Oliva <aoliva at redhat dot com>,Gabriel Dos Reis <gdr at codesourcery dot com>,Jason Merrill <jason at redhat dot com>,gcc-patches <gcc-patches at gcc dot gnu dot org>,libstdc++ <libstdc++ at gcc dot gnu dot org>
- Date: Tue, 26 Mar 2002 08:41:15 +1100
- Subject: Re: [PATCH] Builtins and C++ and such (take 2)
- References: <10670000.1017078905@gandalf.codesourcery.com> <Pine.LNX.4.33.0203251219590.11451-100000@www.eyesopen.com>
On 25-Mar-2002, Roger Sayle <roger@eyesopen.com> wrote:
>
> As Alexandre Oliva and Gabriel Dos Reis have recently explained,
> std::memcpy and ::memcpy are required by the C++ standard to be the
> same function.
>
> I believe that this requires "&std::memcpy == &memcpy" to conform.
> This is the semantics that the posted patch achieves, both functions
> have C linkage and the address of _memcpy is identical for the two.
>
> This would imply that we never use the symbol _ZSt6memcpyPvPKvj.
Not necessarily. That symbol could be an alias for _memcpy
(e.g. using the `alias' attribute.)
> Unfortunately, legacy v3.0.x code, the disabling of builtin
> functions by declaration order and the "-fno-builtin" can be used
> to trick g++ into producing references to these symbols.
I'm not sure if I understand this right... are you saying that
libstdc++ used to define the symbol _ZSt6memcpyPvPKvj,
but now it doesn't? So in other words, your patch breaks
backwards compatibility for the libstdc++ ABI?
Is that an issue? Or is that not a problem,
since the ABI for libstdc++ is not yet frozen?
Does that also imply that with your patch, code that is recompiled with
"-fno-builtin" and which refers to but does not define these functions
will now get unresolved symbol errors, because it will refer to symbols
that libstdc++ does not define? Or will that only happen if the
appropriate system header file is not included?
Note that "-fno-builtin" just means that gcc should not treat the
functions as builtin; it should not prevent the library from defining
them.
If these issues are genuine problems, then it sounds like libstdc++
should be defining the non-builtin versions of these functions,
to preserve ABI compatibility with earlier versions of libstdc++
and to preserve compatibility with code compiled with -fno-builtin.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.