Óscar Fuentes
2013-Jul-31 22:13 UTC
[LLVMdev] MSVC++ ABI compatibility is not a Windows requirement (was: Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI)
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) > goal/feature. > > 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 contrary. 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 way. * 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 minority. 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.
Chris Lattner
2013-Jul-31 22:24 UTC
[LLVMdev] MSVC++ ABI compatibility is not a Windows requirement (was: Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI)
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 whenOk, 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
Chandler Carruth
2013-Jul-31 22:28 UTC
[LLVMdev] MSVC++ ABI compatibility is not a Windows requirement (was: Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI)
First and foremost: this mailing list is simply not an appropriate plate to discuss legal issues. Full stop. I won't reply or discuss them, and please don't try to do so yourself. Find a lawyer if you want to discuss such things. For the rest of your email, I defer to Chris's comments. If you want to convince us there is a better way, please contribute excellent patches that show that better way. Lead by example. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130731/1e736666/attachment.html>
Joshua Cranmer 🐧
2013-Jul-31 22:37 UTC
[LLVMdev] MSVC++ ABI compatibility is not a Windows requirement
On 7/31/2013 5:24 PM, Chris Lattner wrote:> On Jul 31, 2013, at 3:13 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: >> * 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.I would like to add that some of the Windows APIs require C++ ABI and are not (easily) usable from C, so some applications are only viable if Clang can be generally compatible with the MS C++ ABI. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist
João Matos
2013-Aug-01 00:21 UTC
[LLVMdev] [cfe-dev] MSVC++ ABI compatibility is not a Windows requirement
On Thu, Aug 1, 2013 at 1:06 AM, Óscar Fuentes <ofv at wanadoo.es> wrote:> * To understand why they chose to work on MS C++ ABI compatibility > instead of other most basic missing features that preclude using > Clang for serious C++ development. I'll be grateful if anyone > involved on the MS C++ ABI comments on this (it was already mentioned > that Wine is interested on that feature, but I don't understand why.) >Clang is also being increasingly used by tools and having proper MSVC C++ ABI support is very valuable for extracting all kinds of information for interop purposes (record layouts, vftable layouts, mangling, etc).> * To ensure that everybody knows that supporting the MS C++ ABI is not > required at all for being a Windows compiler.It is if you need to use closed source libraries from vendors that only publish MSVC builds. -- João Matos -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130801/330197f1/attachment.html>
Chandler Carruth
2013-Aug-01 00:36 UTC
[LLVMdev] [cfe-dev] MSVC++ ABI compatibility is not a Windows requirement
On Wed, Jul 31, 2013 at 5:06 PM, Óscar Fuentes <ofv at wanadoo.es> wrote:> prompts me to ask if it is right to submit to the mailing lists patches > implementing a feature that is known to be legally "controversial". >I have no idea what you are talking about, but if you have legal or other questions, or want to discuss 'legal controversies', this isn't the right forum. Please do not do it again here. We do not discuss legal issues on this mailing list. This isn't about you, or this subject, or anything. It's simply not an appropriate place *for anyone* to ask about or formulate opinions about legal topics. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130731/ba430570/attachment.html>
Chandler Carruth
2013-Aug-01 00:37 UTC
[LLVMdev] [cfe-dev] MSVC++ ABI compatibility is not a Windows requirement
On Wed, Jul 31, 2013 at 5:06 PM, Óscar Fuentes <ofv at wanadoo.es> wrote:> prompts me to ask if it is right to submit to the mailing lists patches > implementing a feature that is known to be legally "controversial". >I have no idea what you are talking about, but if you have legal or other questions, or want to discuss 'legal controversies', this isn't the right forum. Please do not do it again here. We do not discuss legal issues on this mailing list. This isn't about you, or this subject, or anything. It's simply not an appropriate place *for anyone* to ask about or formulate opinions about legal topics. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130731/d0cafaf2/attachment.html>
Reasonably Related Threads
- [LLVMdev] MSVC++ ABI compatibility is not a Windows requirement (was: Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI)
- [LLVMdev] Switching to the new MingW ABI
- [LLVMdev] [cfe-dev] MSVC++ ABI compatibility is not a Windows requirement
- [LLVMdev] [cfe-dev] MSVC++ ABI compatibility is not a Windows requirement
- [LLVMdev] Switching to the new MingW ABI