This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

Richard Smith


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]