This is the mail archive of the
mailing list for the GCC project.
Re: PATCH: New hook for custom-mangling of C++ scalars
Ziemowit Laski wrote:
Speaking as one of the authors of that portion of the C++ ABI
specification, I disagree.
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'.
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
Please check in your patch, with Zack's documentation.