[PATCH] PR13457 (part 1) explicit/implicit calling conventions compatibility in overloads

[Richard Smith]

On Tue, Mar 19, 2013 at 10:24 AM, Alexander Zinenko <ftynse at gmail.com>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 <richard at metafoo.co.uk> wrote:
>
>> On Fri, Mar 1, 2013 at 2:39 PM, Alexander Zinenko <ftynse at gmail.com>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?
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130320/1ead4bb3/attachment.html>