<div dir="ltr">On Tue, Sep 10, 2013 at 2:25 PM, Charles Davis <span dir="ltr"><<a href="mailto:cdavis5x@gmail.com" target="_blank">cdavis5x@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
  @rsmith wrote:<br>
  > This seems very weird to me. Can you explain a bit about the background for this?<br>
<br>
</div>  Certainly.<br>
<div class="im">  > Is this to support writing variadic __attribute__((ms_abi)) functions when not targeting Win64?<br>
<br>
</div>  Yes. Some software in the wild (Wine, for instance) has variadic `ms_abi` functions. (I wouldn't be surprised, frankly, if this were originally implemented in GCC at the behest of Wine. I know that the `ms_hook_prologue` attribute was.)<br>

<div class="im">  > How is this is supposed to work when we *are* targeting Win64 directly?<br>
<br>
</div>  Exactly the same as a normal `va_list`. I even added a test for this.<br>
<div class="im">  > (Do we get a corresponding __builtin_sysv_va_list to go in the opposite direction, for instance? Are the two types the same in that case?)<br>
<br>
</div>  We don't. Obviously, this is something GCC overlooked--probably because it was implemented specifically so Wine could use it (see above). (To be honest, I contemplated this myself before submitting. I wanted to add an orthogonal extension for `va_list`s in a `sysv_abi` function. But I decided that was better suited for another patch--this one's big enough as it is.)<br>

<div class="im"><br>
<br>
================<br>
Comment at: include/clang/Serialization/ASTBitCodes.h:1343<br>
@@ -1340,1 +1342,3 @@<br>
+      EXPR_LAMBDA,                // LambdaExpr<br>
+      EXPR_MS_VA_ARG              // VAArgExpr (with isMicrosoftABI() true).<br>
     };<br>
----------------<br>
</div><div class="im">Richard Smith wrote:<br>
> Why are you using a separate StmtCode here, rather than just serializing the flag normally?<br>
</div>I think it was because I didn't want to break backwards compatibility with the existing encoding of `clang::VAArgExpr` in a PCH/module. (That's going to become important later when modules are ready for primetime.) But, if you want me to serialize the bit normally, I can go do that.<br>

<div class="HOEnZb"><div class="h5"></div></div></blockquote></div><br></div><div class="gmail_extra">We don't care about PCH backward compatibility at the moment, and that's not likely to change in the near future.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">-Eli</div></div>