[LLVMdev] [cfe-dev] Handling SRet on Windows x86

[Óscar Fuentes]

John Smith <lbalbalba at gmail.com> writes:

> Forgive me from intruding here, but ...
>
> whats wrong with isTargetWin32-MSVC-win32,
> isTargetWin32-mingw32-win32, isTargetWin32-borland-win32,
> isTargetWin32-cygwin-win32, etc.
>
> Judging by the responses, there seems to be a need for that. Which
> leaves the point of what should be 'the default', which could be
> borland for all i care... but perhaps not an as heated discussion ?

The confussion here comes from the fact that on most other platforms
there is one single platform and C++ ABI. The Itanium ABI on
Linux/x86/amd_64 is one example. AFAIK all Linux C++ compilers aim to be
C++ ABI-compatible with g++.

On Windows, there is no such thing as a canonical C++ ABI. There is a
platform ABI that is required for interfacing with the Win32 API, which
is mostly an extension of some previous C ABI. Then, every vendor has
its own C++ ABI (except Intel C++, which aims at being a drop-in
replacement for MSVC++ on Windows and g++ on Linux.) The Windows
platform ABI is supported by all C/C++ compilers out there (and at some
point certain vendors shipped compilers supporting such ABI before MS
itself did.)

Then, there is a plethora of extensions which are required for
interfacing with certain software packages and OS add-ons. Examples are
structured exceptions, COM or .Net. Most of the time (not always) MS was
the first vendor to ship a compiler supporting those extensions, but it
was just another compiler in the field. Then the other vendors went
bananas and MSVC achieved the predominance among the Windows developers.

To the point: from the interest of Clang++ on Windows, it makes no sense
to state that it supports the platform ABI. It must. Then there is the
question about the C++ ABI, and here is where the diversity arises,
because there are quite a few.

It is obvous to me that the target name should mention the compiler that
"defines" the C++ ABI Clang++ is configured for. For instance: mingw,
msvc, borland or whatever. But there is no reason to mention win32
*alone* in the target name because there is no such C++ ABI. Saying that
"win32" implicitly means MSVC++ could be an operative practice, but
would belittle the other players, as if saying that MinGW is less of a
Windows C++ compiler than MSVC. Considering that Clang++ already
implements MinGW C++ ABI but is far from implementing Microsoft's C++
ABI, we certainly don't want that.