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

[Zack Weinberg <zack at codesourcery dot com>]

Ziemowit Laski <zlaski@apple.com> writes:

> Yes, 'int __bool' is an allowable variant of '__bool int'; however,
> the types demangle to '__bool <type>' rather than '<type> __bool':

Oops.  I was using an old version of the demangler.  Never mind.

>> @deftypefn {Target Hook} {const char *} TARGET_MANGLE_SCALAR_TYPE
>> (tree @var{type})
>> If your target defines any extended scalar types, define this hook to
>> return the appropriate encoding for these types as part of a C++
>> mangled name.  The @var{type} argument is the tree structure
>> representing the type to be mangled.  The hook may be applied to trees
>> which are not target-specific extended scalar types; it should return
>> @code{NULL} for all arguments it does not recognize.  If the return
>> value is not @code{NULL}, it is assumed to be a string constant, not a
>> string allocated with malloc.
>>
>> Target-specific scalar types might be new fundamental types or
>> qualified versions of ordinary fundamental types.  Encode new
>> fundamental types as @samp{@w{u @var{n} @var{name}}}, where @var{name}
>> is the name used for the type in source code, and @var{n} is the
>> length of @var{name} in decimal.  Encode qualified versions of
>> ordinary types as @samp{@w{U @var{n} @var{name} @var{code}}}, where
>> @var{name} is the name used for the type qualifier in source code,
>> @var{n} is the length of @var{name} as above, and @var{code} is the
>> code used to represent the unqualified version of this type.  (See
>> @code{write_builtin_type} in @file{cp/mangle.c} for the list of
>> codes.)  In both cases the spaces are for clarity; do not include any
>> spaces in your string.
>>
>> The default version of this hook always returns @code{NULL}, which is
>> appropriate for a target that does not define any extended scalar
>> types.
>> @end deftypefn
>
> 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
<http://www.codesourcery.com/cxx-abi/abi.html#mangling-type>.

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

zw