[cxx-abi-dev] Mangling of calling convention attributes

[John McCall]

> On May 5, 2015, at 3:02 PM, Jason Merrill <jason at redhat.com> wrote:
> On 05/05/2015 05:00 PM, Jason Merrill wrote:
>> ia32 targets support a variety of calling conventions, which correspond
>> to various attributes (cdecl, stdcall, regparm, etc.).  Currently these
>> are not represented in mangling, which leads to problems with template
>> instantiation; I'm thinking about starting to treat them as vendor
>> qualifiers, so given
>> 
>> extern "C" void abort();
>> template <typename F, typename T>
>> void IndirectExternCall(F f, T t1, T t2) {
>>   typedef F (*WrapF)(F);
>>   f (t1, t2);
>> }
>> 
>> __attribute__((regparm(3), stdcall))
>> void regparm_func (int i, int j)
>> {
>>   if (i != 24 || j != 42)
>>     abort();
>> }
>> 
>> void normal_func (int i, int j)
>> {
>>   if (i != 24 || j != 42)
>>     abort();
>> }
>> 
>> int main()
>> {
>>   IndirectExternCall (regparm_func, 24, 42);
>>   IndirectExternCall (normal_func, 24, 42);
>> }
>> 
>> the two instantiations of IndirectExternCall would be mangled
>> differently.  Currently my prototype mangles stdcall as U7stdcall and
>> regparm(3) as U11regparmLi3E, i.e. mangling the attribute argument like
>> a template argument.
> 
> So the first instantiation is
> 
> _Z18IndirectExternCallIPU7stdcallU11regparmLi3EFviiEiEvT_T0_S3_

Okay.  So, basically a qualifier on the function type itself?  Seems reasonable to me.

These qualifiers aren’t order-sensitive, so we need to specify the order; alphabetical order is the most obvious, which I think would make this mangling U11regparmLi3EU7stdcallFviiE rather than the other way around.

For member pointer types, this would become part of the member type.  That’s also where we put ref-qualifiers and CV-qualifiers, so we need to specify an order; I suggest putting these attributes after the CV/ref qualifiers.

Should we mangle these as part of an entity’s type?  It’s not possible to directly overload using the CC of a function itself, so it’s not strictly necessary.  There’s a general issue with overloading function templates by the types of non-type template parameters, but I don’t think it affects us in this specific case because the argument itself resolves the ambiguity.

John.