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

[Richard Smith]

On 5 May 2015 at 15:00, Jason Merrill <jason at redhat.com> 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.
>

It seems a little weird to nest a mangling within a source-name like that.
We had some previous discussion of arguments for vendor extensions here:

http://sourcerytools.com/pipermail/cxx-abi-dev/2014-January/002660.html

It looks like we ended up mangling

  void f(bool b) __attribute__((enable_if(b, "foo"))) {}

as

  _Z1fUa9enable_ifIXfL0p_EEb

... where Ua means roughly "vendor attribute", and is followed by
<source-name> <template-args>. With that approach, those attributes would
mangle as Ua7regparmIXLi3EE and Ua7stdcallIE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20150505/89fbe6d1/attachment.html>