Re: C++ ABI: name mangling of operator new [bug 6057]

[Gabriel Dos Reis <gdr at cs dot tamu dot edu>]

Richard Smith <richard@ex-parrot.com> writes:

| About five years ago, I reported a bug about an ICE when
| trying to mangle expressions involving operator new.
| 
|   http://gcc.gnu.org/ml/gcc-patches/2002-03/msg01417.html
|   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6057
| 
| A three line example exhibiting the ICE is:
| 
|   template <unsigned int> struct helper {};
|   template <class T> void check( helper<sizeof(new T)>* );
|   int main() { check<int>(0); }
| 
| As I understand it, the reason that this has never been
| fixed is that a full fix requires either an extension/change
| to the ABI which presumably requires collaboration between
| the eight organisations that produced it.
| 
| I'm wondering whether there's any prospect of this
| happening, and if not, whether GCC should use the vendor
| extension syntax (v <digit> <source-name>) to provide a fix?
| 
| As it stands, the ABI's definition of mangling a new
| expression makes no sense as it has no way of folding the
| type into the mangled name.  (It doesn't even say whether
| operator new is to be regarded as a unary operator, per the
| C++ standard, or binary or ternary.  In terms of the
| information needed in the mangled name, it should be ternary
| as there are placement arguments, the type, and constructor
| arguments.)
| 
| Although the bug only manifests in fairly arcane code, it
| can nevertheless occur in legal code: I've generally
| encountered it when developing type traits using template
| metaprogramming.

We discussed that issue again at that last ISO C++ meeting
in Toronto.

(1) while people usually refer to name mangling as a "blocking"
    issue, it appears to me as bogus:  Nowhere the C++ standard
    talks of "name mangling".

(2) it is generally accepted in the ISO C++ Core Working sub-Group
    that compiler writers will have to mangle general expressions.

(3) the real issue is deeper:  during template argument deduction
    and template instantiation, define what is a "hard error" and
    what is "substitution failure is not error".  The line is not
    as clear cut as one might believe at fist sight.

(4) the record of the ISO C++ Core Issue #339 is not up-to-date and
    does not reflect the current thinking of the CWG.

Finally, at the last meeting, I made the claim that if the
implementation detail issue (name mangling) is solved then, all of the
examples discussed so far in the record of the CWG issue #339 are
handled fine by GCC/g++ as of today -- with no modification to the
template or overload machinery.  On Wednesday July 18, 2007 I brought
factual evidence to that claim by showing g++ behaviour on all of the
examples discussed (including those from the "decltype" proposal).
(All I did was to encode call expressions, new expressions and a few
other tree nodes). 

Note also that GCC/g++ will not encode __typeof, but it would encode
__alignof -- which is a plain bug, not to be lumped with issue 339.

-- Gaby