[LLVMdev] Handling SRet on Windows x86

[Joe Groff]

On Thursday, March 28, 2013, Óscar Fuentes wrote:

> Chandler Carruth <chandlerc at google.com <javascript:;>> writes:
>
> >> And here there is no "Windows ABI" here at all. Because every compiler
> >> (MSVC, gcc / clang, Borland) does its own stuff. This is why I said
> >> that the proposal naming is confusing.
> >>
> >
> > I don't know anything about Borland, and I don't think that matters. But
> I
> > think that the Windows ABI is, and really must be, the ABI followed by
> the
> > system compiler: MSVC.
>
> MSVC is not the system compiler. Certainly, it is not distributed with
> the system. Actually, MSVC was a secondary player on Windows for a long
> time, with several other C++ ABI-incompatible options available.


It isn't shipped with the system, but it's freely available as part of the
Windows SDK, and most binary library packages for Windows are shipped as
MSVC binaries.


>
> This is so wrong.
>
> OTOH, do you really want to present MSVC++ as the canonical Windows
> compiler? That not only puts down MinGW (let's forget about the
> propietary Borland/Embarcadero compiler for a moment) but it is against
> Clang++ too, which is not going to reach MSVC++ compatibility anytime
> soon, but it is not far away from being usable for Windows development,
> as MinGW g++ is. You are effectively proposing that we should send the
> message that Clang++ is a second class citizen on Windows development.
>

*-*-win32 and *-*-mingw32 are different targets. Aside from C++, it's
useful to be able to use Clang as an MSVC compatible C99 compiler, since
MSVC itself only supports C89, and it's useful for LLVM to be usable by
other frontends that want MSVC compatibility. The win32 target can provide
that independent of the mingw target, which should of course remain
compatible with mingw's ABI.

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130328/416af880/attachment.html>