<div dir="ltr"><div><div>This sounds like the right direction to me, if Anton's OK with removing the mangling from LLVM.</div><div><br></div><div>-  virtual bool shouldMangleDeclName(const NamedDecl *D) = 0;</div><div>
+  bool shouldMangleDeclName(const NamedDecl *D);</div><div>+  virtual bool shouldMangleDeclNameImpl(const NamedDecl *D) = 0;</div><div> </div><div>   // FIXME: consider replacing raw_ostream & with something like SmallString &.</div>
<div>-  virtual void mangleName(const NamedDecl *D, raw_ostream &) = 0;</div><div>+  void mangleName(const NamedDecl *D, raw_ostream &);</div><div>+  virtual void mangleNameImpl(const NamedDecl *D, raw_ostream &) = 0;</div>
</div><div><br></div><div>Rather than mangleNameImpl, how about mangleCXXName?  Basically, the shared code is C / asm mangling only, and the ABI-specific code is all C++.</div><div><br></div><div>....</div><div><br></div>
<div>+static bool isStdOrFastCallFunc(const ASTContext &Context,</div><div>+                                const NamedDecl *ND) {</div><div>+  llvm::Triple Triple = Context.getTargetInfo().getTriple();</div><div>+  if (!Triple.isOSWindows() || Triple.getArch() != llvm::Triple::x86 ||</div>
<div>+      Context.getLangOpts().CPlusPlus)</div><div>+    return false;</div><div>+</div><div>+  const FunctionDecl *FD = dyn_cast<FunctionDecl>(ND);</div><div>+  if (!FD)</div><div>+    return false;</div><div>+  QualType T = FD->getType();</div>
<div>+  const AttributedType *AT = dyn_cast<AttributedType>(T);</div><div>+  if (!AT)</div><div>+    return false;</div><div>+  AttributedType::Kind Kind = AT->getAttrKind();</div><div>+  return Kind == AttributedType::attr_stdcall ||</div>
<div>+         Kind == AttributedType::attr_fastcall;</div><div>+}</div><div><br></div><div>Don't look for the attributed type, it won't be there with -mrtd, for example.  That'd be a good test, btw.  You can pull the true CC directly from FunctionType::getCallConv().</div>
<div><br></div><div>...</div><div><br></div><div><div>+    unsigned ArgWords = 0;</div><div>+    for (FunctionProtoType::arg_type_iterator Arg = Proto->arg_type_begin(),</div><div>+                                              ArgEnd = Proto->arg_type_end();</div>
<div>+         Arg != ArgEnd; ++Arg) {</div><div>+      QualType AT = *Arg;</div><div>+      // Size should be aligned to DWORD boundary</div><div>+      ArgWords += (ASTContext.getTypeSize(AT) + 31) / 32;</div><div><br></div>
<div>Grumble grumble RoundUpToAlignment().</div><div><br></div><div>+    }</div><div>+    Out << 4 * ArgWords;</div></div><div><br></div><div>...</div><div><br></div><div><div><div>diff --git a/test/CodeGen/mangle-ms.c b/test/CodeGen/mangle-ms.c</div>
<div>new file mode 100644</div><div>index 0000000..6706492</div><div>--- /dev/null</div><div>+++ b/test/CodeGen/mangle-ms.c</div></div></div><div><br></div><div>mangle-windows.c seems more accurate.</div><div><br></div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 9, 2013 at 12:45 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 9 October 2013 14:48, Anton Korobeynikov <<a href="mailto:anton@korobeynikov.info">anton@korobeynikov.info</a>> wrote:<br>

>> Doesn't mingw need these manglings to match the Windows C ABI?<br>
> Correct, it does need it.<br>
<br>
</div>Good catch. The attached patch handles mingw too.<br>
<div class="im"><br>
> Another problem, which is much more severe, is that moving mangling in<br>
> clang will force non-clang users to handle the mangling by themselves.<br>
<br>
</div>Judging from<br>
<a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-February/059626.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-February/059626.html</a><br>
<br>
that would be an welcome change. The mangling consists of adding how<br>
many bytes are used for arguments. If a frontend can produce a call at<br>
all it has that information.<br>
<br>
In any case. This patch changes only clang. Even if we decide to not<br>
change llvm, I think this patch is an improvement as it makes it<br>
possible for us to test that clang produces the desired name for C<br>
code (as we do for C++ already).<br>
<div class="im"><br>
> Also, keep in mind, that gcc on linux does support stdcall / fastcall<br>
> calling conventions, but does not mangle the stuff.<br>
<br>
</div>That is also handled correctly.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div>