[LLVMdev] MSVC++ ABI compatibility is not a Windows requirement (was: Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI)
ofv at wanadoo.es
Wed Jul 31 15:13:08 PDT 2013
Chris Lattner <clattner at apple.com> writes:
> This thread is odd to me. It seems that the gist of your guys'
> argument is that you don't know if we will ever get full support,
> therefore we don't welcome progress towards that (very useful)
> If the specific proposal doesn't make make sense from a design
> standpoint, that's one thing, but saying we shouldn't take it because
> of licensing issues with MFC or because it is harmful to be partially
> (but not fully) compatible with MSVC seems just weird to me.
Full disclosure: I'm the guy who filled the PR requesting the feature
the OP's is working on and, when someone tried to close it as WONTFIX, I
strongly opposed. Furthermore, MSVC++ is my Windows compiler and my
projects suffer from unwelcome complexity for working around the lack of
this feature on LLVM.
So I hope it is obvious that I'm not against Reid's proposal, quite the
My point is that nowadays Clang++ is not a production-ready Windows
compiler. The missing features are much easier to implement than MS C++
ABI compatibility. For starters, they are well documented. So it
perplexes me to see the flux of work on MS C++ compatibility when:
* It is an open ended, difficult, uncertain goal. You'll never know for
sure that it is done.
* Obviously, if you don't implement the features that every Windows C++
compiler must have, you'll never be compatible with MS. Currently
Clang++ cannot create or use C++ dlls (a series of patches were
submitted but quickly rejected, I hope that Nico was not discouraged
by this.) OTOH, implementing 32bit SEH is a must-have requirement for
MS compatibility, but it would benefit Clang on Windows independently
of the C++ ABI used.
* For being the best Windows C++ compiler, Clang++ doesn't need to be
compatible with the MS C++ ABI. However (and this is highly
detrimental to Clang, IMO) from reading the mailing lists one could
easily get the impression that until Clang++ gets the MS C++ ABI, it
is not ready for Windows. It wont surprise me to learn that some
contributors are working on the MS C++ ABI because they think that
* Using its current C++ ABI and debug info format on Windows has the
advantage of making Clang++ usable together with tools like existing
debuggers and profilers. For using Clang with Visual Studio's IDE it
must learn how to emit debug info compatible with MS, and that is
another can of worms.
* As the MS C++ ABI is in flux, while at the same time Clang++ is well
ahead of MS on conformance, some weird cases might arise where
Clang++ would be forced to extend the ABI on its own at the risk of
being incompatible with itself after a while (MS variadic templates
implementation required an ABI change. MS engineers admit that
planned features might require more changes. Of course, Clang++
already supports most of those features.)
* Finally, legal issues remain: supposing that Clang++ gets MS C++ ABI
compatibility, is it possible to use MS C++ runtime(s) and libraries
with Clang++? We could end with lots of work invested on a feature
that only benefits those who are forced to work with third-party C++
libraries distributed on binary form. I guess that such users are a
To recap: lots of work is being invested on a feature which is very hard
to implement, while at the same time Clang lacks basic features. I'll
dare to say that focusing the effort on those features would mean that,
in a year at most, Clang would become the best C++ compiler for Windows.
Needles to say, everyone has the right to decide on what they work. I
fully respect that. But I'll like to know what motivates those who are
working so hard on the MS C++ ABI while Clang++ remains as a compiler
not ready for production on Windows.
More information about the llvm-dev