This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: C++ ABI: name mangling of operator new [bug 6057]
On Fri, 27 Jul 2007, Richard Smith wrote:
| > | The general philosophy in the current ABI would seem to be
| > | that the expression is encoded in terms of its template
| > | parameters, and not with the evaluated expression with the
| > | subsituted argument.
| >
| > That is correct. For a compiler, such as GCC, that uses parse trees
| > to represent a template declaration there is no additional
| > difficultly in mangling the expression, compared to the 'ordinary' case.
|
| My concern is how, practically, to mangle a call to an
| overloaded function, as, if the philosophy of encoding the
| expression in terms of template parameters is continued, you
| have to introduce ways of mangling the linked list of
| FUNCTION_DECLs in an OVERLOAD node.
We discussed this issue in CWG. We don't need to encode the overload
set. In fact, the only requirement we have is we select the same
function in all contexts, not that the overload set must be the same.
| This is certainly not
| impossible, but likely to be long-winded. And the
| possibility of ADL means that the overload set won't be the
| same for each instantiation of the template
Yes, that is OK as long as the selected function is the same
for each instantiation with same template and same arguments.
| E.g. in
|
| int foo(int); long foo(long);
| template <int> A {};
| template <class T, T V> void bar( A<sizeof(foo(V))> );
|
| we could introduce
|
| O <overloads expression-list> E
I would suggest to just represent the expression sizeof(foo(V))
as a simple (linerized) tree. I don't think we been to say which
foo() is to be selected. "foo" by itself is already a good representation
of the overload set implied.
| to represent a overload set and represent the sizeof
| expression as
|
| szcl2OL_Z3fooiEL_Z3foolEET0_
|
| (where I've adopted your mangling of call expression rather
| than the one I suggested).
|
|
| A better approach might be to fall back to the token stream
| and mangle the token stream representing the function being
| called.
I believe the representation of token stream is all that is needed
(that is what I did in my quick demo to CWG). Certainly simply
encoding the overload set will not match the semantics as implied
by the C++ standard.
| E.g. in the same way that
|
| sr <type> <unqualified-name>
|
| gives you a way of mangling sizeof( T::foo() ), a variant
| could be introduced for unqualified names, e.g.
|
| su <unqualified-name>
|
| which would allow the original sizeof(foo(V)) to be mangled
| as
|
| szcl2su3fooT0_
Is the "su" to indicate that the "foo" really is unprocessed, as opposed
to one that is processed? Could we do without it?
| which is much more concise than mangling the overload set,
| and more accurately reflects the 'same token stream'
| requirement of the standard.
Yes.
| (Though, 14.6.4.1/7 already
| makes the program ill-formed, no diagnostic required, if a
| specialisation has different meanings at different points of
| instantiation, so the difference can only affect ill-formed
| programs, I think.)
Yes.
[...]
| > | _Z3barI{parameters}Ev1AIXszclL_Z3fooIiEiT_ET0__EE
| > |
| > | ... because the 'i' from T=int is repeated. (Again, this is
| > | only a problem if one wants to mangle two 'functionally
| > | equivalent' overloads.)
| >
| > The killing point for GCC/g++ is to mangle the original template
| > declaration -- not just the result of instantiation -- that is close
| > to the 'same token stream' requirement of the C++ definition.
|
| But does this have to be a killing point for GCC?
No, it does not have to. I was reporting the current situation.
-- Gaby