Richard Smith <[EMAIL PROTECTED]> 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
