<div dir="ltr"><div>+  // Diagnose the use of X86 fastcall on unprototyped functions.<br></div><div><br></div><div>We should also diagnose unprototyped stdcall functions, but I'm not sure if that would be too disruptive.  Currently we accept this and always call _f@0:</div>
<div><div>void __stdcall f();</div><div>int main() {</div><div>  f(1);</div><div>  f(1, 2);</div><div>  f(1, 2, 3);</div><div>}</div></div><div><br></div><div>MSVC rejects with "t.c(5) : error C2708: 'f' : actual parameters length in bytes differs from previous call or reference".</div>
<div><br></div><div><div>+  QualType NewQType = Context.getCanonicalType(NewFD->getType());</div><div>+  const FunctionType *NewType = cast<FunctionType>(NewQType);</div><div>+  FunctionType::ExtInfo NewTypeInfo = NewType->getExtInfo();</div>
<div>+  if (NewTypeInfo.getCC() == CC_X86FastCall) {</div><div>+    if (isa<FunctionNoProtoType>(NewType)) {</div><div>+      Diag(NewFD->getLocation(), diag::err_cconv_knr)</div><div>+          << FunctionType::getNameForCallConv(CC_X86FastCall);</div>
<div>+    }</div><div>+</div><div>+    // Also diagnose fastcall with regparm.</div><div><br></div><div>Before you moved this, there was other code to handle CC_X86FastCall and AT_Regparm nearby.  I think we should either move all regparm+fastcall diagnosis to after redeclaration merging or leave it where it is.</div>
<div><br></div><div>+    if (NewType->getHasRegParm()) {</div><div>+      Diag(NewFD->getLocation(), diag::err_attributes_are_not_compatible)</div><div>+          << "regparm" << FunctionType::getNameForCallConv(CC_X86FastCall);</div>
<div>+    }</div><div>+  }</div></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jul 26, 2014 at 3:05 PM, Nico Weber <span dir="ltr"><<a href="mailto:thakis@chromium.org" target="_blank">thakis@chromium.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>the attached patch delays semantic analysis of __fastcall until after MergeFunctionDecl() has been called, PR20386.</div>
<div><br></div><div>The motivation is code like this in a .c file:</div>
<div><br></div><div><div>void __fastcall CrcGenerateTable(void);</div><div>void __fastcall CrcGenerateTable() {}</div></div><div><br></div><div>Without this patch, __fastcall is analyzed before the definition of CrcGenerateTable() is merged with the declaration, so Sema thinks the function doesn't have a prototype. Since the error is only emitted on FunctionNoProto functions, and functions in C++ or functions with more than 0 arguments have a proto, this is only an issue for functions with 0 parameters in C files. See the bug for some more notes.</div>

<div><br></div><div>(A side effect of moving the diagnostic is that the diagnostic now points at the function instead of the attribute, and that the attribute is no longer marked invalid. Neither seems like a problem.)</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>Nico</div></font></span></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>