On Tue, Mar 19, 2013 at 10:24 AM, Alexander Zinenko <[email protected]>wrote:
> 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? > FunctionDecls have both a canonical type and a type as written. This transformation should only be applied to the canonical type. > 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
