[LLVMdev] MSVC++ ABI compatibility is not a Windows requirement (was: Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI)

[Chris Lattner]

On Jul 31, 2013, at 3:13 PM, Óscar Fuentes <ofv at wanadoo.es> wrote:
> 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.

Good to know.

> 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

Ok, and it is fine for you to share your opinion.  However, as an open source project, we generally don't have the luxury of telling contributors how they should spend their time.  Suggesting to Chip (or anyone) that there are interesting other problems to solve is one thing, but standing in the way of progress because you think there are higher priorities is another.

> * It is an open ended, difficult, uncertain goal. You'll never know for
>   sure that it is done.

Well sure.  If you rewind 5 years, people were saying the same thing about GCC compatibility.  :-)

> * 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.

Same comment.  Clang still doesn't have openmp or nested function support.  It is still useful.

> * 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
>   way.

Fair point, but being ABI compatible DOES enable certain applications, for example, working with existing binaries that can't be recompiled.

> * 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.)

I don't know enough to comment on this, but I don't think that all people interested in using clang on windows necessarily care.

>  * 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
>   minority.

You need the technology first, once technology issues are solved, legal issues can be tackled.  It is certainly true that people within Microsoft would love great clang support, perhaps in time the right legal agreements can be hammered out.

> 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.

As I said up front, it is fine for you to share your opinion about what is matter (you're clearly a smart guy and very knowledgeable), please just don't turn this into blocking progress that you personally aren't interested in or don't value.

-Chris