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

[Óscar Fuentes]

Joe Groff <arcata at gmail.com> writes:

> On Thu, Mar 28, 2013 at 12:19 PM, Óscar Fuentes <ofv at wanadoo.es> wrote:
>
>> What do you mean by "the full platform"? Every propietary extension that
>> MS came with along all these years? (From structured exceptions to
>> whatever Windows RT requires?)
>>
>> MinGW is very well capable of using the Win32 API. There is partial or
>> non-existent support for extensions such as COM, but those are not part
>> of the "ABI", for sure.
>>
>
> Mingw interoperates with the Win32 API, yes, but it's able to without
> having full C ABI compatibility with MSVC. For one, most of the Win32 API
> has its own "stdcall" calling convention, which is different from either
> Mingw's or MSVC's "cdecl" ABIs. The Win32 API also avoids passing or
> returning structs or other non-primitives by value, because C and Pascal
> compilers back in the early 90s didn't behave consistently outside of a
> small subset of C functionality, and MSVC and Mingw still don't.

If MinGW lacks some parts of the Windows platform ABI, that is
considered something to fix by the MinGW community. Another question is
the real possibiities of fixing the discrepancy, given the available
manpower, expertise and perceived urgency by the MinGW community.

Put it another way: I doubt you will encounter a MinGW maintainer that
could say that implementing full C compatibility with MSVC is not
something they would like to achieve.

In that sense, the point is not about making a MinGW ABI-compatible
Clang, but a MinGW bug-compatible Clang.

>> Irrelevant too, since those "MSVC binaries" (whatever that means) are
>> usable by the other compilers.
>>
>
> Not unless the library authors take pains to only export APIs that conform
> to the subset of MSVC's and Mingw's ABIs that are compatible.

In my experience, the differences are not so widely used to be glaring.
I'm writing this message on a editor which was compiled with MSVC but
uses about a dozen C libraries compiled with MinGW. In any case, I
concede that a difference is a difference and it is a good thing that
Clang knows about it.

I have no objections about that. What I object about is to declaring
some vendor's compiler as a privileged component, all others (including
Clang) being second class.