Hi Eric,> From my perspective Win32 is the windows ABI and mingw and cygwin are their own ABIsNo. 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). 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
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
On Wed, Mar 27, 2013 at 2:28 PM, Anton Korobeynikov <asl at math.spbu.ru>wrote:> 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). > > 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++. >I don't think anyone disagrees here, but we don't differentiate between C ABI and C++ ABI in this context really (we don't have two ABI strings in the triple). The ABI designator must specifi *both* the C and C++ ABI. As such, mingw and cygwin have their own holistic ABI -- it is a conjunction of two pieces of other ABIs.> 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. That's the standard for the platform, and I think it is actively confusing to say that the "Windows ABI" could mean anything other than what MSVC as the standard system compiler does. It certainly should have nothing to do with mingw or cygwin. This is why I suggest that the Windows ABI is whatever MSVC happens to do. The mingw ABI happens to consist of a conjunction of what MSVC does for C and what GCC on Linux does for C++. That is a unique and different ABI, and I don't think you can reasonably call it *just* "windows" at any point. -Chandler -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130327/1b1a4a9e/attachment.html>
Chandler Carruth <chandlerc at google.com> 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.> That's the standard for the platform, and I think it > is actively confusing to say that the "Windows ABI" could mean anything > other than what MSVC as the standard system compiler does. It certainly > should have nothing to do with mingw or cygwin.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.> This is why I suggest that the Windows ABI is whatever MSVC happens to > do.There is another argument against that: the MSVC++ ABI is undocumented. The real "Windows ABI" (i.e. what your compiler needs to do for interfacing with the OS) is not.
On Wed, Mar 27, 2013 at 8:15 PM, Chandler Carruth <chandlerc at google.com>wrote:> This is why I suggest that the Windows ABI is whatever MSVC happens to do. > The mingw ABI happens to consist of a conjunction of what MSVC does for C > and what GCC on Linux does for C++. That is a unique and different ABI, and > I don't think you can reasonably call it *just* "windows" at any point. > > This isn't quite true. Mingw and MSVC's ABIs on i386 also differ at the Clevel—for instance, alignment of pass-by-value structs sometimes differs, and an sret pointer is callee-cleanup in MSVC but caller-cleanup in Mingw. There are other differences too. -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130328/0eb98d82/attachment.html>
On Thu, Mar 28, 2013 at 8:22 AM, Joe Groff <arcata at gmail.com> wrote:> On Wed, Mar 27, 2013 at 8:15 PM, Chandler Carruth <chandlerc at google.com>wrote: > >> This is why I suggest that the Windows ABI is whatever MSVC happens to >> do. The mingw ABI happens to consist of a conjunction of what MSVC does for >> C and what GCC on Linux does for C++. That is a unique and different ABI, >> and I don't think you can reasonably call it *just* "windows" at any point. >> >> This isn't quite true. Mingw and MSVC's ABIs on i386 also differ at the C > level—for instance, alignment of pass-by-value structs sometimes differs, > and an sret pointer is callee-cleanup in MSVC but caller-cleanup in Mingw. > There are other differences too. >Can you clarify what you mean by the "sret pointer is callee-cleanup" vs caller-cleanup? What we were specifically hitting yesterday was that MSVC expects the sret pointer passed into also be returned in eax. LLVM already does this for x86_64 everywhere. Mingw doesn't do this, but I think it was just a coincidence. This behavior was undocumented, and that there was probably no OS API takes a callback which returns a struct larger than 8 bytes. This makes me think that it would be better if we started returning the sret pointer from such functions under Mingw for improved compatibility at the C ABI level. This shouldn't break any mingw code so far as I can tell. It seems reasonable for a user to expect that the Mingw and Microsoft C ABIs be compatible, but maybe there are enough other corner cases that this is just naive. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130328/c17d0712/attachment.html>
> 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) > ?You need to make sure you won't break the compatibility with gcc on mingw. Regardless whether this is a) or b) -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
On Mar 28, 2013, at 1:35 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: Oscar, just FYI, your wording is very strong, and that is often not the most productive way to make your point. That said, to address some of the things you've raised in a couple of threads:>> If you think these are irrelevant points then you need to state why >> and should back it up with less dismissive language. > > Sorry, but this goes the other way. If you need a lesson in history > please start by investigating what "Borland" was, for instance. As > already mentioned, for a long time MSVC was considered an inferior > option and not required in any way for developing on Windows (not even > for device drivers!) Then Borland and the other vendors were displaced > by MSVC, but not because it was "the system compiler", nor even because > it was technically better overall, severely lacking in C++ compliance, > for instance.These are some pretty broad strokes, but overall this is mostly true. I agree that the notion of a "system compiler" doesn't particularly exist in the windows domain. There is a strong notion of the "system APIs" though (including the crazy extensions), and one could reasonably conclude that whatever is required to build against those APIs qualifies as a system compiler. However, that is just arguing terminology and not the actual interesting point of this thread :)> Sorry if I sound dismissive but it's quite irritating to see how > authoritativeness is attributed to something that doesn't deserve it > *to* *the* *detriment* *of* *our* *own* *project*.I don't see this. Support for the *visual studio ABI* in all of its glory is not a detriment to anyone. It would be detrimental if we *didn't* support the mingw ABI also, but noone is arguing to support VC++ ABI but drop mingw.> I'm saying that anything that could suggest that MSVC++ is more > desirableYou cannot argue about desirability as though everyone thinks the same way. Some people care a lot more about VC++ compatibility (including COM and many other things!) than they do about mingw. You need to be able to accept that, and the project as a whole is driven by people writing code. If someone wants to contribute patches to improve VC++ compatibility then we should take them (of course, not if they break mingw).> than the other compilers is not only unfair, but would go > against Clang's interest because Clang will sooner get full MinGW > drop-in capability than MSVC++ drop-in capability.This doesn't make any sense to me. In principle, Clang should support both and users can pick whichever one suits their needs best. If someone wanted to come along and contribute clang language support for some weird COM or WinRT thing, and if their patches were well written and fit into the rest of the compiler properly, we should take them. I don't think anyone is saying that *you* should stop working on mingw and start implementing VC++ support, but by the same token, you shouldn't tell *them* what they are supposed to care about. -Chris
Chris Lattner <clattner at apple.com> writes:> On Mar 28, 2013, at 1:35 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: > > Oscar, just FYI, your wording is very strong, and that is often not > the most productive way to make your point. That said, to address some > of the things you've raised in a couple of threads:I don't think that my wording was so strong to raise offense on anyone. On other communities were I participate, "strong wording" is used for conveying determination and energy, never be taken as a personal attack. But my English is not as good as I would like and too often I miss nuances on words and phrasings that could be misinterpreted by some readers. Certainly you are a better English speaker than me, so I'll take your advice and apologize if someone got the impression that I was being offensive or arrogant.>> I'm saying that anything that could suggest that MSVC++ is more >> desirable > > You cannot argue about desirability as though everyone thinks the same > way. Some people care a lot more about VC++ compatibility (including > COM and many other things!) than they do about mingw. You need to be > able to accept that, and the project as a whole is driven by people > writing code. If someone wants to contribute patches to improve VC++ > compatibility then we should take them (of course, not if they break > mingw). > >> than the other compilers is not only unfair, but would go >> against Clang's interest because Clang will sooner get full MinGW >> drop-in capability than MSVC++ drop-in capability. > > This doesn't make any sense to me. In principle, Clang should support both and users can pick whichever one suits their needs best. > > If someone wanted to come along and contribute clang language support > for some weird COM or WinRT thing, and if their patches were well > written and fit into the rest of the compiler properly, we should take > them. > > I don't think anyone is saying that *you* should stop working on mingw > and start implementing VC++ support, but by the same token, you > shouldn't tell *them* what they are supposed to care about.My English is really bad, because you interpreted my message on a way that has no relation at all with my position :-) I said that Clang++ will be compatible (*) with MinGW sooner than with MSVC++ because much of the work for MinGW compatibility is already done (since Clang aimed at compatibility with gcc since day 1) and for what is left you have descriptive documentation and/or examples of implementation. That's not true for MSVC++ and, contrary to MinGW's case, nobody is in a position of saying "with X months of effort the work could be completed, modulo bugs." I think it is totally reasonable to think that Clang will take a long time to be compatible (*) with MSVC++. That's why I say that any message that puts any other compiler on an inferior status to MSVC++ is not only unfair, but prejudicial to Clang too. If we refer to MSVC++ on our mailing lists and source code as the "Windows system compiler", not only are we being factually wrong and dismissive of other vendors' work, but we would be picturing Clang as if the best thing it could ever achieve on Windows is some level of compatibility with the "system compiler." As someone who is developing Windows software using C++ for 20 years, I can categorically say that it is a very damaging and completely false message: Clang can be a better Windows C++ compiler than MSVC++ even if it does not follow its C++ ABI (+). LLVM/Clang mailing lists are read by lots of current and new developers and its source examined by lots of future compiler engineers. We should take care about not propagating false beliefs, and extra care when they damage us. * Compatible as in "usable enough with the runtimes and SDKs distributed with such compiler for compiling standard C++ sources that uses the Win32 API." + I'm all for adding MSVC++ ABI support to Clang.