This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: New hook for custom-mangling of C++ scalars
On 22 Mar, 2004, at 10.55, Zack Weinberg wrote:
Ziemowit Laski <zlaski@apple.com> writes:
Actually, I'm not even certain that the AltiVec extended scalar
types meet either of these definitions. :-( For example, is 'bool
int' really a qualified version of an ordinary fundamental type?
It is, in the narrow sense that that's the mangling you are using for
it: "U6__bool" is the encoding of a vendor-defined type qualifier
"__bool". I don't know myself whether calling "__bool" a type
qualifier is appropriate to the normal definition of "type qualifier"
or the semantics of that extension.
Well, your comments actually lead me to rephrase my argument more
succintly: namely, just because vendor types utilize certain
features of the C++ mangling spec, this does not necessarily imply
that they share semantic characteristics of other types that may
happen to use the same mangling machinery. The reason that we (or
Metrowerks, actually) chose the mangling that we did is that
the types _demangle_ very nicely, with no need to modify the
demangler. :-) But I think that reading more into this scheme
is unwarranted.
For me the logic goes the other way around. The "extended builtin
type" and "extended type qualifier" encodings are the only hooks that
vendors have to define special types, see. My goal is to discourage
people from extending the mangling scheme in an incompatible manner.
So what I want to get across is that u<n><name> and U<n><name><code>
are the available options, and then give some idea of when it would be
appropriate to use each.
Perhaps, more generally, the allowable manglings are
( U<n>name) * ( u<n>name | code )
?
I definitely 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'.
Turning to AltiVec, we chose to mangle '__bool int' as "U6__booli",
but we could have also mangled it as "U6__boolu3int"! In other
words, the fact that 'int' is part of the type name need not have
semantic significance; we just chose to encode it as 'i' because
it was shorter. :-)
So I guess my only disagreement with you is that we should not infer
any additional meaning ("type qualifiers", etc.) from the mangling
that is chosen.
--Zem
--------------------------------------------------------------
Ziemowit Laski 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group Cupertino, CA USA 95014-2083
Apple Computer, Inc. +1.408.974.6229 Fax .5477