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

["Doug Gregor" <doug dot gregor at gmail dot com>]

Hi Richard,

On 7/26/07, Richard Smith <richard@ex-parrot.com> wrote:
> 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?

This kind of thing came up that the last C++ committee meeting, as
part of core issue 339:

 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#339

Name mangling is part of the problem, but not all of it. There is also
the issue of what happens when there is an error in the expression
"new T": is it part of the Substitution Failure Is Not An Error
(SFINAE) rule, meaning that the function would not enter the overload
set, or does it trigger an error immediately? That's actually the more
complicated issue.

As for GCC... I think we realize that we do have to fix these
problems. That means we'll need name mangling for all of the
expressions (and will have to extend the C++ ABI for this; vendor
extensions would not be useful), and we'll have to update a lot of the
type-checking for expressions in the C++ front end to propagate and
obey tsubst_flags_t.

 - Doug