This is the mail archive of the 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]

Re: PATCH: New hook for custom-mangling of C++ scalars

Ziemowit Laski wrote:

nitely do see your point in that any new types that get added in
should never collide (mangling-wise, at least) with any existing types,
and that the 'u' and 'U' encodings are a way to accomplish this.  Another
requirement is that the types should demangle to a human-readable form
that is consistent with their how users actually write them.  So, if
some target defines a special type called '__target __special __type'
(however idiotic that may be), then the mangling simply _must_ be
'U8__targetU9__specialu6__type', because that will demangle to
'__target __special __type'.

Speaking as one of the authors of that portion of the C++ ABI specification, I disagree.

Zack is correct: the choice of 'U' and 'u' is a semantic one, based on whether the thing encoded is a qualifier or a new basic type. The original idea was that 'U' was around for Microsoft's "near" and "far", and 'u' was around for things like HP's "__fpreg". You have chosen to treat "__bool" as a qualifer for AltiVec, which seems fine. That means that you thikn of "__bool int" as a kind of int, rather than a type whose name happens to have a space in it.

Worrying about demangling, however, is entirely the wrong motivation for making these distinctions. It may well be that if your target has some special types, then your demangler needs some special logic to demangle those special types. Treating the demangler as immutable is not appropriate.

Please check in your patch, with Zack's documentation.


Mark Mitchell
CodeSourcery, LLC
(916) 791-8304

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