This is possible when acting on FunctionDecl, but it can affect diagnostics reporting in the following way: when outputting FunctionType with non-default CC, diagnostics engine assumes CC was specified explicitly via __attribute__ syntax. I am not sure this is a desired behavior. It would be better if there was a way to work around this, does it exist?
By the way, we already have such behavior if an unknown CC is automatically replaced with CC_C on some targets, like here void __stdcall foo(); double x = foo; cannot initialize a variable of type 'double' with an lvalue of type 'void () __attribute__((cdecl))' On 19 March 2013 00:32, Richard Smith <[email protected]> wrote: > On Fri, Mar 1, 2013 at 2:39 PM, Alexander Zinenko <[email protected]>wrote: > >> Hello! >> >> This patch addresses the compatibility issue between explicitly specified >> default calling conventions and implicit ones in overload resolution. As >> of now, such implicit conversions are only known in Microsoft ABI. The >> corresponding CodeGen already knows about these implicit defaults, so the >> conversion kind could be just NoOp. >> >> The patch covers: >> * pointers to free functions (__cdecl by default); >> * references to free functions; >> * pointers to static member functions and variadic member functions >> (__cdecl by default); >> * pointers to non-static non-variadic member functions (__thiscall by >> default); >> * simultaneous calling convention adjustment and base-to-derived implicit >> conversion for member functions. >> >> The patch does not cover function templates, although the approach to >> this is exactly the same as for PR15291. >> >> I suppose functions for determining calling convention compatibility >> could be moved somewhere in TargetCXXABI if needed in other places. >> >> Please, review! >> Suggestions are welcome. >> > > This seems rather more brute force than is required. Could you instead > transform CC_Default to Context.getTargetInfo().getDefaultCallingConv(...) > in the relevant places? >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
