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

On 21 Mar, 2004, at 21.23, Zack Weinberg wrote:
@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
@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 <>.

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.

My thoughts,

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

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