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

Timur Iskhodzhanov timurrrr at google.com
Wed Mar 27 19:35:25 PDT 2013


2013/3/27 Anton Korobeynikov <asl at math.spbu.ru>:
> Hi Eric,
>
>> From my perspective Win32 is the windows ABI and mingw and cygwin are their own ABIs
> No. They are using Windows Platform ABI for almost everything (e.g.
> calling API, C runtime, etc.). At least mingw does. The differences
> are exactly in unspecified area (e.g. passing / returning structs by
> value).

OK, what do we plan to do in the unspecified areas?

A more specific question is - if I fix some Clang i686-pc-win32
compatibility issue with MSVC for some language feature (e.g.
returning a struct),
should I make sure Clang i686-pc-mingw32 behavior is not changed by my
patches (a)
or should I make sure that Clang i686-pc-mingw32 generates
MSVC-compatible ABI for the same feature (b)
?

> The only difference is C++, where mingw / cygwin follows Itanium ABI
> and MSVC - its own.
>
>> especially as we're not targeting the MSVC abi, it's just the windows
>> abi?
> It seems the proposal patch exactly tries to follow MSVC ABI to keep
> to compatibility :)
>
> So, just to summarize. Windows ABI / calling conventions are more or
> less documented and both mingw / cygwin and msvc follow it.
>
> The differences are in the undocumented area. Both for C and for C++.
> 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.
>
> --
> With best regards, Anton Korobeynikov
> Faculty of Mathematics and Mechanics, Saint Petersburg State University
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev



More information about the llvm-dev mailing list