On 5 May 2015 at 15:00, Jason Merrill <[email protected]> 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
_______________________________________________ cxx-abi-dev mailing list [email protected] http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
