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 <> 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.

There certainly may be a better way to phrase that.  Ideas?


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