Re: [PATCH] Builtins and C++ and such (take 2)

[Roger Sayle <roger at eyesopen dot com>]

> > One side-effect of disabling the built-in, is that functions that
> > used to get C linkage due to the previously anticipated prototype,
> > end up with C++ linkage.   This results in warnings about unresolved
> > references to std::abs and std::sqrt during linking (which should
> > be references to _abs and _sqrt).
>
> Let me back up and ask a slightly different question: does this reflect
> a bug in V3 or a bug in the compiler?  In other words, are there now
> conforming programs whose meaning will be misconstrued by the compiler?
>
> It didn't seem to me that your patch would do that, which would imply
> that V3 was relying on functions magically getting the right linkage?
>
> Perhaps you can explain this to me in a bit more detail?


I'd like to say that this has been a bug in V3, but in reality V3 and
the behavior of g++ are so initimately linked that neither side is solely
to blame.  Without the V3 changes, there are no regressions is either
the gcc or g++ testsuites, so V3 has relied on g++'s actual implementation
rather than its prescribed behavior.

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.
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.

This can be seen as a good thing.  If someone wishes to use the
symbol std::memcpy for their own purposes (without including any
standard or system headers), g++ allows it, and gives it a suitably
mangled linkage, which doesn't conflict which the definition given
by the system's standard C library.


I believe that the only code that could be bitten by this "feature"
are implementations of standard C library functions in the C++ std
namespace, that use overloading, i.e. sqrt(float) and sqrt(double).
And even then, the problem only exists if the expected declaration
isn't provided first.


[I apologise for this patches effect on the interaction between the
g++ front-end and libstc++.  During its development, I investigated
a shorter patch that re-used the same DECL for ::memcpy and std::memcpy.
In this case, I was caught by the fact that on glibc systems, math.h,
wanted to redefine sqrt, and libstdc++'s cmath wanted to redefine
std::sqrt.  Getting all three parties to agree on a solution looked
unlikely.  If these header's just defined the function prototypes
to entries in their libraries things would have been much easier :>]


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