<div dir="ltr">On Tue, Mar 26, 2013 at 1:39 PM, Alexander Zinenko <span dir="ltr"><<a href="mailto:ftynse@gmail.com" target="_blank">ftynse@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Hello Richard, Timur,</div><div><br></div>
<div>I tried different approaches to this issue, but they are not elegant enough as for me.</div><div><br></div><div>The first is to replace CC_Default with explicit default CC in declarations. It requires changing function, typedef, variable and parameter declarations to address our problem. But this approach results in over 20 test failures due to diagnostics change (adds extra __attribute__ to function type). Although attribute printing is not perfect now since it prints __attribute__((cdecl)) instead of __cdecl, adding extra attributes in the output may be unwanted.</div>
</div></blockquote><div><br></div><div style>I talked to Richard last week, and I think we agreed that this is the way to go. There are two places where it matters if the CC is implicit or explicit: merging attributes on redeclaration, and type printing. In both cases, you should be able to detect an explicit calling convention by looking for AttributedType sugar.</div>
<div style><br></div><div style>Is this something you can work on in the near future, or would it be OK if I looked into this approach? You have awesome tests, by the way. :)</div><div style><br></div><div style>I think DeclaratorChunk might need more information in order to get the CC right to handle cases like:</div>
<div style>struct Foo {</div><div style><div> void (*(*foo())())();</div>};</div><div style><br></div><div style>If I didn't spell it right, that's supposed to be a method that returns a function ptr that returns a function ptr. Parameters have their own parsing context, so that's not an issue.</div>
<div style><br></div><div style>Similarly, a member function pointer type would need to use thiscall. I believe the whole declarator is parsed in a MemberContext, so that isn't enough info to pick the CC.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Another one is to try changing only the canonical type. Function canonical types are handled in ASTContext::getFunctionType and we already have a notion of canonical calling convention (for MRTD). But MS ABI has different default calling conventions for instance methods and everything else. FunctionType does not differentiate between method types and free function types as well as has no information about storage classes. We can introduce extra arguments with default values to getFunctionType, but it might clutter the code and doesn't look like a good idea.</div>
<div><br></div><div>The third one is the inverse to the first: change explicit default CCs to CC_Default. This doesn't work because it breaks declaration merge:</div><div>void __cdecl foo(); // CC_C is default, so drop it. Becomes equivalent to void foo().</div>
<div>void __stdcall foo(); // Set CC_X86StdCall since the previous was without CC (we dropped it).</div><div><br></div><div>And the last one is my initial approach in overload resolution.</div><div><br></div><div>I would like to have an advice which approach do we prefer?</div>
<div><br></div></div><div class=""><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On 20 March 2013 23:19, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>On Tue, Mar 19, 2013 at 10:24 AM, Alexander Zinenko <span dir="ltr"><<a href="mailto:ftynse@gmail.com" target="_blank">ftynse@gmail.com</a>></span> wrote:<br>
</div><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">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?</div>
</blockquote><div><br></div></div><div>FunctionDecls have both a canonical type and a type as written. This transformation should only be applied to the canonical type.</div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div>By the way, we already have such behavior if an unknown CC is automatically replaced with CC_C on some targets, like here</div><div><div>void __stdcall foo(); double x = foo;<br></div><div>cannot initialize a variable of type 'double' with an lvalue of type 'void () __attribute__((cdecl))'<br>
</div></div><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 19 March 2013 00:32, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div>On Fri, Mar 1, 2013 at 2:39 PM, Alexander Zinenko <span dir="ltr"><<a href="mailto:ftynse@gmail.com" target="_blank">ftynse@gmail.com</a>></span> wrote:<br>
</div></div><div class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">Hello!<div><br></div><div>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.</div>
<div><br></div><div>The patch covers:</div><div>* pointers to free functions (__cdecl by default);</div><div>* references to free functions;</div><div>* pointers to static member functions and variadic member functions (__cdecl by default);</div>
<div>* pointers to non-static non-variadic member functions (__thiscall by default);</div><div>* simultaneous calling convention adjustment and base-to-derived implicit conversion for member functions.</div><div>
<br></div><div>The patch does not cover function templates, although the approach to this is exactly the same as for PR15291.</div><div><br></div><div>I suppose functions for determining calling convention compatibility could be moved somewhere in TargetCXXABI if needed in other places.</div>
<div><br></div><div>Please, review!</div><div>Suggestions are welcome.</div></div></blockquote><div><br></div></div></div><div>This seems rather more brute force than is required. Could you instead transform CC_Default to Context.getTargetInfo().getDefaultCallingConv(...) in the relevant places?</div>
</div>
</blockquote></div><br></div></div></div></div></div></div>
</blockquote></div></div><br>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
<br></blockquote></div><br></div></div>