Chris Bieneman
2014-Aug-22 16:58 UTC
[LLVMdev] [RFC] Raising LLVM minimum required MSVC version to 2013 for trunk
> On Aug 22, 2014, at 9:53 AM, Daniel Dilts <diltsman at gmail.com> wrote: > > On Fri, Aug 22, 2014 at 9:42 AM, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote: > Starting a new thread to loop in cfe-dev and lldb-dev. For those not following along there has been a thread on llvm-dev about moving the minimum required Visual Studio version to 2013. The motivating reason is this will allow us to take advantage of a bunch of C++11 features that are not supported by MSVC 2012. > > Is there an existing policy on how supported compiler versions are selected?There was a discussion last year (http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066847.html <http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066847.html>) WRT allowing LLVM to use C++11 features which established a precedent of supporting compilers released back for two years, with a special caveat for Windows. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140822/6259bcbf/attachment.html>
Daniel Dilts
2014-Aug-22 17:09 UTC
[LLVMdev] [RFC] Raising LLVM minimum required MSVC version to 2013 for trunk
On Fri, Aug 22, 2014 at 9:58 AM, Chris Bieneman <beanz at apple.com> wrote:> > On Aug 22, 2014, at 9:53 AM, Daniel Dilts <diltsman at gmail.com> wrote: > > On Fri, Aug 22, 2014 at 9:42 AM, Chris Bieneman <beanz at apple.com> wrote: > >> Starting a new thread to loop in cfe-dev and lldb-dev. For those not >> following along there has been a thread on llvm-dev about moving the >> minimum required Visual Studio version to 2013. The motivating reason is >> this will allow us to take advantage of a bunch of C++11 features that are >> not supported by MSVC 2012. >> > > Is there an existing policy on how supported compiler versions are > selected? > > > There was a discussion last year ( > http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066847.html) WRT > allowing LLVM to use C++11 features which established a precedent of > supporting compilers released back for two years, with a special caveat for > Windows. > > -Chris >>From the link:*we support building with the **most recent 2 versions of VS available at the *prior* release. For example** when we branch for 3.4, the two versions will be 2012 and 2013. Those two** would be supported on mainline from then through 3.5, and when we branch** for 3.5 we would re-evaluate. * If that is followed exactly support for VS2012 would not be able to be dropped. However, it is rather easy to get the latest VC++ compiler from Microsoft at no cost (Express edition anybody?), so I don't have any real concern with dropping support for VS2012. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140822/e13fd439/attachment.html>
DeadMG
2014-Aug-22 17:24 UTC
[LLVMdev] [cfe-dev] [RFC] Raising LLVM minimum required MSVC version to 2013 for trunk
Officially, the latest two major versions- so MSVC 2012 and 2013. The main issue I'd see here is that all of those features are relatively untested- for example, in VS 14 CTP3 they had to introduce a new error to explicitly break all the cases where the compiler silently did totally the wrong thing. The ones that were included in VS2012 CTP are not quite as bad. But the reality of using VS2013 is not that all of these features will suddenly be available to use- there's a lot of compiler issues that would need to be worked around, including some silently-generates-totally-the-wrong-code bugs. They can also report totally incorrect errors- e.g. reporting errors that have nothing to do with the real error, in totally the wrong location, or both. Seeing the feature list seems compelling, but MSVC's actual support is often still below the standard you can find in GCC or Clang, even in officially supported features. There's a price to be paid not just in terms of breaking users who are still VS2012-dependent, but also in terms of debugging VS2013-only bugs. Personally, I think that it's worth upping the minimum requirement whenever you're not breaking a substantial portion of your userbase. All I'm saying is, the experience of many of us using VS2013 is that that feature list is a little ... optimistic. Upgrading on that basis alone may well yield undesirable results. Perhaps it would be better to consider a fork, where the new features are employed, and then if it doesn't introduce new bugs, it could be merged. This would also give more time for people to report in with a VS2012 dependency. On 22 August 2014 17:58, Chris Bieneman <beanz at apple.com> wrote:> > On Aug 22, 2014, at 9:53 AM, Daniel Dilts <diltsman at gmail.com> wrote: > > On Fri, Aug 22, 2014 at 9:42 AM, Chris Bieneman <beanz at apple.com> wrote: > >> Starting a new thread to loop in cfe-dev and lldb-dev. For those not >> following along there has been a thread on llvm-dev about moving the >> minimum required Visual Studio version to 2013. The motivating reason is >> this will allow us to take advantage of a bunch of C++11 features that are >> not supported by MSVC 2012. >> > > Is there an existing policy on how supported compiler versions are > selected? > > > There was a discussion last year ( > http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066847.html) WRT > allowing LLVM to use C++11 features which established a precedent of > supporting compilers released back for two years, with a special caveat for > Windows. > > -Chris > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140822/e0dc72ec/attachment.html>
Chris Bieneman
2014-Aug-22 18:01 UTC
[LLVMdev] [RFC] Raising LLVM minimum required MSVC version to 2013 for trunk
> On Aug 22, 2014, at 10:09 AM, Daniel Dilts <diltsman at gmail.com> wrote: > > > > > On Fri, Aug 22, 2014 at 9:58 AM, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote: > >> On Aug 22, 2014, at 9:53 AM, Daniel Dilts <diltsman at gmail.com <mailto:diltsman at gmail.com>> wrote: >> >> On Fri, Aug 22, 2014 at 9:42 AM, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote: >> Starting a new thread to loop in cfe-dev and lldb-dev. For those not following along there has been a thread on llvm-dev about moving the minimum required Visual Studio version to 2013. The motivating reason is this will allow us to take advantage of a bunch of C++11 features that are not supported by MSVC 2012. >> >> Is there an existing policy on how supported compiler versions are selected? > > There was a discussion last year (http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066847.html <http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066847.html>) WRT allowing LLVM to use C++11 features which established a precedent of supporting compilers released back for two years, with a special caveat for Windows. > > -Chris > > From the link: > we support building with the most recent 2 versions of VS available at the *prior* release. For example when we branch for 3.4, the two versions will be 2012 and 2013. Those two would be supported on mainline from then through 3.5, and when we branch for 3.5 we would re-evaluate. > > > If that is followed exactly support for VS2012 would not be able to be dropped. However, it is rather easy to get the latest VC++ compiler from Microsoft at no cost (Express edition anybody?), so I don't have any real concern with dropping support for VS2012. >Also from that link: One short term caveat: Windows is special. I don't think we should follow the 2-year rule for Windows. It really is special for at least three reasons: 1) We can't bootstrap on Windows. While there is tons of exciting work going on here to change that, even then the quality of Windows support is likely to change very rapidly. 2) Visual Studio's C++ support moved very slowly for a long time, and is now improving at an amazing rate. We shouldn't be hampered by past problems and should take advantage of this recent progress. 3) We have less insight into when new versions of the MSVC++ toolchain will arrive. I feel it is also worth recognizing that by the time we branch for 3.6 the two most recent versions of Visual Studio will probably be 2013 and 14, so we’re really only proposing moving forward a few months early. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140822/ee2ac882/attachment.html>
Renato Golin
2014-Aug-23 20:24 UTC
[LLVMdev] [cfe-dev] [RFC] Raising LLVM minimum required MSVC version to 2013 for trunk
On 22 August 2014 20:18, Óscar Fuentes <ofv at wanadoo.es> wrote:> I second this. My experience with VS is that new features are usually > broken if you go beyond the simple cases. And the roadmaps have little > credibility, based on a continuous flow of disappointments since... > forever.Is there any interest from Microsoft to actually fix those problems, or is that their policy that what's there is there? The latter seems to be their policy on other products, and for what I know, VS too. I ask that because holding on partial and broken support that will never be fixed or completed is kind of backwards. I'm not a Windows guy, but I wonder why so many people use MSVC if the support is so patchy and hopeless as most people seem to imply. Also, compiling Clang with MSVC and making Clang MSVC compatible are two completely different things. A commercial toolchain based on MSVC compatibility doesn't necessarily need to be compiled with MSVC itself. Or maybe the Windows environment is so alien that I'm basing my points on completely unreasonable assumptions... cheers, -renato
DeadMG
2014-Aug-23 20:55 UTC
[LLVMdev] [cfe-dev] [RFC] Raising LLVM minimum required MSVC version to 2013 for trunk
MSVC survives because there's no effective competition- it's like communications providers in the United States or political parties in China. The alternatives like GCC have no decent development environments for them, and Clang has the bonus of not being mature w.r.t. things like Standard libraries. The reality is, there's nowhere to go *but* MSVC. This stuff is the major reason why I'd positively love clang-cl. As soon as that is done, then support for cl can probably be entirely dropped and the state of the available compilers will be drastically improved. Microsoft *is* issuing more and more out-of-band bugfix updates. But the current state for VS2013 is still that most bugfixes will hit in VS "14" (currently projected for 2015). On 23 August 2014 21:24, Renato Golin <renato.golin at linaro.org> wrote:> On 22 August 2014 20:18, Óscar Fuentes <ofv at wanadoo.es> wrote: > > I second this. My experience with VS is that new features are usually > > broken if you go beyond the simple cases. And the roadmaps have little > > credibility, based on a continuous flow of disappointments since... > > forever. > > Is there any interest from Microsoft to actually fix those problems, > or is that their policy that what's there is there? The latter seems > to be their policy on other products, and for what I know, VS too. I > ask that because holding on partial and broken support that will never > be fixed or completed is kind of backwards. > > I'm not a Windows guy, but I wonder why so many people use MSVC if the > support is so patchy and hopeless as most people seem to imply. Also, > compiling Clang with MSVC and making Clang MSVC compatible are two > completely different things. A commercial toolchain based on MSVC > compatibility doesn't necessarily need to be compiled with MSVC > itself. > > Or maybe the Windows environment is so alien that I'm basing my points > on completely unreasonable assumptions... > > cheers, > -renato > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140823/d6d01697/attachment.html>
Alex Rosenberg
2014-Aug-24 01:05 UTC
[LLVMdev] [cfe-dev] [RFC] Raising LLVM minimum required MSVC version to 2013 for trunk
On Aug 23, 2014, at 1:24 PM, Renato Golin <renato.golin at linaro.org> wrote:> > Also, > compiling Clang with MSVC and making Clang MSVC compatible are two > completely different things. A commercial toolchain based on MSVC > compatibility doesn't necessarily need to be compiled with MSVC > itself.But it must. If you want to be able to use LLVM DLLs inside a Windows app, it has to be built with MSVC because they have their own C++ ABI. At some point, Clang will support Microsoft's ABI well enough to consider a bootstrap instead. Alex
Yaron Keren
2014-Aug-24 07:45 UTC
[LLVMdev] [cfe-dev] [RFC] Raising LLVM minimum required MSVC version to 2013 for trunk
"Why do developers make such ridiculous statements about broken tools?" Richard, clang on Windows is not completely compatible with either mingw or Visual C++ toolchains so it's not (yet! clang is improving all the time) a practical alternative. 1) clang TLS is not compatible with mingw implementation emutls, so no C++11 concurrency. (anyone know of a solution?) 2) clang does not produce debug information in Visual C++ format (except for line infromation), so no debugging. I'm not sure is SEH support is ready in clang. This leaves a C++ developer two main choices, the mingw toolchain or the Visual C++ one. I'm not choosing based on brouchures or blog posts. I do work with both toolchains extensively. My preference for development work is working around the C++ limitations of Visual C++ in exchange for developing under Visual Studio IDE which I find most productive. YMMV, please, I'm not trying to start a flame war. Ideally, I'd like to see clang completely support Visual C++ ABI and debugging info so we'll have the best solution, clang with Visual Studio and integrated debugger. Yaron 2014-08-24 4:49 GMT+03:00 Óscar Fuentes <ofv at wanadoo.es>:> Alex Rosenberg <alexr at leftfield.org> writes: > > > On Aug 23, 2014, at 1:24 PM, Renato Golin <renato.golin at linaro.org> > wrote: > >> > >> Also, > >> compiling Clang with MSVC and making Clang MSVC compatible are two > >> completely different things. A commercial toolchain based on MSVC > >> compatibility doesn't necessarily need to be compiled with MSVC > >> itself. > > > > But it must. If you want to be able to use LLVM DLLs inside a Windows > > app, it has to be built with MSVC because they have their own C++ ABI. > > This is false. LLVM libraries can be used on C++ Windows applications > just fine without using MSVC at all. > > > At some point, Clang will support Microsoft's ABI well enough to > > consider a bootstrap instead. > > AFAIK Clang bootstraps on MinGW-w64. > > To go back on topic: C++ features advertised by MSVC as recently > supported usually are too immature to be used on practice. So looking at > a brochure is not enough when deciding what you gain when you upgrade > your MSVC install. > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140824/5798a24d/attachment.html>
Renato Golin
2014-Aug-24 12:22 UTC
[LLVMdev] [cfe-dev] [RFC] Raising LLVM minimum required MSVC version to 2013 for trunk
On 24 August 2014 08:45, Yaron Keren <yaron.keren at gmail.com> wrote:> Ideally, I'd like to see clang completely support Visual C++ ABI and > debugging info so we'll have the best solution, clang with Visual Studio and > integrated debugger.Amidst all the flame, there's one truth coming out of it, and one that we already have a firm opinion: following broken tools is not a wise path. And by broken here, I don't mean MSVC, I mean GCC. While there are many good things coming out of GCC at any moment in time, not all that comes is gold, and we took the decision long ago to not blindly follow what GCC does just because "bacon". I'd rather not do that with MSVC either. In the same way that both GCC and MSVC are broken, Clang/LLVM is *also* broken, and anyone following us, will have a hard time. I had to do that myself at one time, and it wasn't pleasant. LLVM is a mature library, Clang is a mature compiler, but we still don't have a mature toolchain like both GCC and MSVC have on either Linux or Windows and very likely not even on Darwin. That all means two things: 1. We can't complain about others before having a working toolchain that is stable, widely used and with a mission that isn't "work as a replacement to <foo>". 2. We'll have to choose our path, which will probably not be the same as any other toolchain exactly, and we have to stick to it. The fact that we're sticking to rational decisions is finally changing the source code of many lazy developers that thought that GCC was the only option. A few examples are the Linux kernel, the Android system and the Chromium browser. I'd love to see the same effort and determination on the Windows side, as I hear many horror stories of patchy support and people having nightmares about it. Though, I have no idea where to start, as I haven't used Windows for almost two decades. I agree with Chandler, lets go back to the matter a hand. But the result might be, from Alex's answer, that we can't do it just now. My only point in this email is: shall we try harder? Shall we try to liberate horrified users, like we're doing with the other toolchain? :D cheers, --renato
Alex Rosenberg
2014-Aug-24 14:58 UTC
[LLVMdev] [cfe-dev] [RFC] Raising LLVM minimum required MSVC version to 2013 for trunk
On Aug 23, 2014, at 6:49 PM, Óscar Fuentes <ofv at wanadoo.es> wrote:> Alex Rosenberg <alexr at leftfield.org> writes: > >> On Aug 23, 2014, at 1:24 PM, Renato Golin <renato.golin at linaro.org> wrote: >>> >>> Also, >>> compiling Clang with MSVC and making Clang MSVC compatible are two >>> completely different things. A commercial toolchain based on MSVC >>> compatibility doesn't necessarily need to be compiled with MSVC >>> itself. >> >> But it must. If you want to be able to use LLVM DLLs inside a Windows >> app, it has to be built with MSVC because they have their own C++ ABI. > > This is false. LLVM libraries can be used on C++ Windows applications > just fine without using MSVC at all.If the main executable is built with MSVC's C++ ABI, then what are you going to build LLVM with that even links? MinGW doesn't use the MSVC C++ ABI. Clang-cl dosn't generate PDB data. The only available option is MSVC.>> At some point, Clang will support Microsoft's ABI well enough to >> consider a bootstrap instead. > > AFAIK Clang bootstraps on MinGW-w64.MinGW doesn't implement the same C++ ABI at all. It implements the Itanium ABI like we use on every other platform.> To go back on topic: C++ features advertised by MSVC as recently > supported usually are too immature to be used on practice. So looking at > a brochure is not enough when deciding what you gain when you upgrade > your MSVC install.Agreed. Let's get back to the original proposal, which was for us to abandon our established policy and drop a version of MSVC that we support in order to use variadic templates to rewrite cl::opt. Alex
Colin Riley
2014-Aug-25 08:58 UTC
[LLVMdev] [lldb-dev] [cfe-dev] [RFC] Raising LLVM minimum required MSVC version to 2013 for trunk
LLDB supports building with 2013 only. This has been the situation for some time now, so from our side I don't see any problems. On 24/08/2014 15:58, Alex Rosenberg wrote:> On Aug 23, 2014, at 6:49 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: > >> Alex Rosenberg <alexr at leftfield.org> writes: >> >>> On Aug 23, 2014, at 1:24 PM, Renato Golin <renato.golin at linaro.org> wrote: >>>> Also, >>>> compiling Clang with MSVC and making Clang MSVC compatible are two >>>> completely different things. A commercial toolchain based on MSVC >>>> compatibility doesn't necessarily need to be compiled with MSVC >>>> itself. >>> But it must. If you want to be able to use LLVM DLLs inside a Windows >>> app, it has to be built with MSVC because they have their own C++ ABI. >> This is false. LLVM libraries can be used on C++ Windows applications >> just fine without using MSVC at all. > If the main executable is built with MSVC's C++ ABI, then what are you going to build LLVM with that even links? MinGW doesn't use the MSVC C++ ABI. Clang-cl dosn't generate PDB data. The only available option is MSVC. > >>> At some point, Clang will support Microsoft's ABI well enough to >>> consider a bootstrap instead. >> AFAIK Clang bootstraps on MinGW-w64. > MinGW doesn't implement the same C++ ABI at all. It implements the Itanium ABI like we use on every other platform. > >> To go back on topic: C++ features advertised by MSVC as recently >> supported usually are too immature to be used on practice. So looking at >> a brochure is not enough when deciding what you gain when you upgrade >> your MSVC install. > Agreed. Let's get back to the original proposal, which was for us to abandon our established policy and drop a version of MSVC that we support in order to use variadic templates to rewrite cl::opt. > > Alex > > > _______________________________________________ > lldb-dev mailing list > lldb-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev-- - Colin Riley Games Technology Director Codeplay Software Ltd 45 York Place, Edinburgh, EH1 3HP Tel: 0131 466 0503 Fax: 0131 557 6600 Website: http://www.codeplay.com Twitter: https://twitter.com/codeplaysoft