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

Zack Weinberg <> writes:

> > I have mixed feelings here.  While I agree that it's good to point out
> > that these extended scalar types must follow the C++ ABI mangling
> > rules for vendor extensions, I don't quite see why it is necessary
> > to narrowly define these types as 'new fundamental types' or
> > 'qualified versions of ordinary fundamental types'. 
> Those are the choices you have.  u<n><name> is a "builtin extended
> type" and U<n><name> is an "extended type qualifier", to use the
> terminology of the C++ ABI document.  See
> <>.
> > 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.

I'll just throw in a comment that the mangling ABI is, IMHO, broken
with respect to demangling of vendor-defined type qualifiers.  The ABI
says that for purposes of substitution order-sensitive and
order-insensitive vendor-defined type qualifiers must be handled
differently, but the ABI provides no way for a demangler to determine
which vendor-defined type qualifiers are order sensitive and which are
order insensitive.  Therefore, both demanglers which I know about
treat all vendor-defined type qualifiers as order sensitive.

For example, the standard type qualifiers const and volatile are order
insensitive, in that "const volatile int" and "volatile const int"
name the same type.

This is just something to consider when adding a new type qualifier.
Is "const QUAL int" equivalent to "QUAL const int"?  If they are
equivalent, then the qualifier is order insensitive.  If you follow
the requirements of the mangling ABI, the demanglers will not be able
to correctly demangle certain uses of that qualifier.


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