[PATCH] Support __builtin_ms_va_list.

[Eli Friedman]

On Tue, Sep 10, 2013 at 2:25 PM, Charles Davis <cdavis5x at gmail.com> wrote:

>
>   @rsmith wrote:
>   > This seems very weird to me. Can you explain a bit about the
> background for this?
>
>   Certainly.
>   > Is this to support writing variadic __attribute__((ms_abi)) functions
> when not targeting Win64?
>
>   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.)
>   > How is this is supposed to work when we *are* targeting Win64 directly?
>
>   Exactly the same as a normal `va_list`. I even added a test for this.
>   > (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?)
>
>   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.)
>
>
> ================
> Comment at: include/clang/Serialization/ASTBitCodes.h:1343
> @@ -1340,1 +1342,3 @@
> +      EXPR_LAMBDA,                // LambdaExpr
> +      EXPR_MS_VA_ARG              // VAArgExpr (with isMicrosoftABI()
> true).
>      };
> ----------------
> Richard Smith wrote:
> > Why are you using a separate StmtCode here, rather than just serializing
> the flag normally?
> 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.
>

We don't care about PCH backward compatibility at the moment, and that's
not likely to change in the near future.

-Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130910/30696b1f/attachment.html>