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 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>
Joe Groff <arcata at gmail.com> writes:>> 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,That's a recent development which is irrelevant to this discussion. g++ and clang++ are freely available too.> and most binary library packages for Windows are shipped as > MSVC binaries.Irrelevant too, since those "MSVC binaries" (whatever that means) are usable by the other compilers.> *-*-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.It only makes sense to talk about "MinGW's ABI" vs "MSVC ABI" in the context of C++, so your mention of C99 is also irrelevant.