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

[Gabriel Dos Reis <gdr at codesourcery dot com>]

Roger Sayle <roger@eyesopen.com> writes:

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


I'm not sure I'm following you here.  

Because V3 assumes C linkage for the C library function we couldn't
have been using the symbol _ZSt6memcpyPvPKvj.  Indeed, each time
'name' has a C linkage, the standard text requires  X::name and
Y::name , for any namespaces X and Y to refer to the same entity:

7.5/5

  [...] 6 At most one function with a particular name can have C
  language linkage. Two declarations for a function with C language
  linkage with the same function name (ignoring the namespace names
  that qualify it) that appear in different namespace scopes refer to
  the same function. Two declarations for an object with C lan-guage
  linkage with the same name (ignoring the namespace names that
  qualify it) that appear in different namespace scopes refer to the
  same object. [...]


So, I don't think there were a bug in V3 in that regard.

| 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 would strongly oppose to that "feature", unless of course, ::memcpy
is given a C++ linkage, but then (it should designate the same
function as std::memcpy, therefore practically ended up being mangled
as std::memcpy).

| 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 :>]

Welcome to C++ implementation world :-)

-- Gaby