On Tue, Oct 31, 2017 at 6:26 PM, Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote:> > On Tue, Oct 31, 2017 at 3:19 PM Justin Bogner <mail at justinbogner.com> > wrote: > >> Zachary Turner <zturner at google.com> writes: >> >> > If 3 months later we started requiring C++17, someone could build clang >> 6 >> > with the system compiler and then build Clang ToT. >> > >> > If 3 months later we started requiring C++20, someone could still build >> > clang 6 with the system compiler and then build Clang ToT. >> > >> > Every relaxation of the kind of code we can use in LLVM does not >> > necessitate an extra hop in the bootstrapping process, because existing >> > versions of clang can already compile through C++20. >> > The feature set of C++20 is not closed yet by the committee. I don't seewhere this is coming from (but if you would like to share, then please do tell).> >> I hate to exaggerate, but this sounds almost like an argument for using >> new C++ features the day after we implement them. There obviously has to >> be some balance here. >> > > Someone could probably use that line of reasoning to argue for using new > features immediately after implementing them, but that someone wouldn't be > me :) > > In any case, the point was simply to illustrate that, in general, you do > not need to add a hop to the bootstrapping process every time you bump the > language standard. C++20 is 4-6 years out before we're even discussing it > though, and any discussion we have about if, when, or how to move to it now > will probably be irrelevant by that time. > > For C++14 and C++17 though, I think the argument still holds. System > Compiler -> {GCC 7 or Clang 5-6} -> ToT >Copies of C++17 are not available for sale yet. There will likely be tweaks in the wording and in the implementation. It would be quite unfortunate to pick up C++17 for development on ToT only to discover 3 years afterwards that some range of revisions can only be built properly with some specific build compilers with a particular bug/interpretation of the feature.> > should require only 1 hop regardless of language standard, and that covers > us for quite a while. > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171031/c2a5e98f/attachment.html>
On Tue, Oct 31, 2017 at 3:45 PM Hubert Tong < hubert.reinterpretcast at gmail.com> wrote:> On Tue, Oct 31, 2017 at 6:26 PM, Zachary Turner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> On Tue, Oct 31, 2017 at 3:19 PM Justin Bogner <mail at justinbogner.com> >> wrote: >> >>> Zachary Turner <zturner at google.com> writes: >>> >>> > If 3 months later we started requiring C++17, someone could build >>> clang 6 >>> > with the system compiler and then build Clang ToT. >>> > >>> > If 3 months later we started requiring C++20, someone could still build >>> > clang 6 with the system compiler and then build Clang ToT. >>> > >>> > Every relaxation of the kind of code we can use in LLVM does not >>> > necessitate an extra hop in the bootstrapping process, because existing >>> > versions of clang can already compile through C++20. >>> >> The feature set of C++20 is not closed yet by the committee. I don't see > where this is coming from (but if you would like to share, then please do > tell). > > >> >>> I hate to exaggerate, but this sounds almost like an argument for using >>> new C++ features the day after we implement them. There obviously has to >>> be some balance here. >>> >> >> Someone could probably use that line of reasoning to argue for using new >> features immediately after implementing them, but that someone wouldn't be >> me :) >> >> In any case, the point was simply to illustrate that, in general, you do >> not need to add a hop to the bootstrapping process every time you bump the >> language standard. C++20 is 4-6 years out before we're even discussing it >> though, and any discussion we have about if, when, or how to move to it now >> will probably be irrelevant by that time. >> >> For C++14 and C++17 though, I think the argument still holds. System >> Compiler -> {GCC 7 or Clang 5-6} -> ToT >> > Copies of C++17 are not available for sale yet. There will likely be > tweaks in the wording and in the implementation. It would be quite > unfortunate to pick up C++17 for development on ToT only to discover 3 > years afterwards that some range of revisions can only be built properly > with some specific build compilers with a particular bug/interpretation of > the feature. > >Technically correct (the best kind). But I don't have a CL up for review that I'm waiting to commit which changes the standard, nor am I even proposing moving to C++17 in the immediate future (indeed, in the original post I mentioned at least one compiler does not have *any* feature complete C++17 implementation available, and is actually a ways out from having one, and certainly we couldn't consider adopting C++17 until every supported compiler has *some* version that is feature complete). C++14 is a different story, and that was part of the reason for the original post. There is definitely interest from many people to at least --have a plan-- for bumping the standard. So the goal of this is to work this plan out. With MSVC we have a very clear, tangible policy of "we support the two latest major releases of MSVC". This is what I'm trying to get at. ---What is the policy for GCC?--- It seems like we don't have one. I would like to have an actual, concrete, specific, well-defined rule that people can refer to decide when we can bump the minimum required GCC version. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171031/b76aa9fc/attachment.html>
Not to rain on the GCC parade, but all this loose talk about bootstrapping our way into using C++20 is making me real nervous. I think the MSVC limiting factor is a real one. My company delivers a pile of products to a whole lot of game developers, and those products are (nearly) all built with MSVC. MSVC is a solid toolchain with a long track record, and actually supports the Windows environment moderately well. ;-) With all due respect to the folks working on Clang/LLVM's Windows support (and I've even done a tiny bit of it myself), we are nowhere near willing to build our products with such a relatively untried Windows-target tool as Clang itself. In support of Windows Clang, I will say it has advanced to the point where my team has floated the thought of having an agenda item on a planning meeting to talk about what it would take to work up an experimental build/test pipeline to try out the idea of evaluating the possibility that we could potentially consider adopting Clang as the build compiler for our toolchain. I am probably stating that too strongly. More concisely: Given the two-version policy for MSVC, what MSVC(-1) supports is an upper bound on what version of C++ the LLVM project can really adopt. Now I do understand this is not what zturner is actually asking; he's asking, how do we decide when to move the *lower* bound, which is somehow caught up in the practicalities of what's delivered with which distros and how important is that really. In order to advance the lower bound to C++14, the issue is, can we require people to have GCC 5? End of problem statement. Thanks for listening, --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Zachary Turner via llvm-dev Sent: Tuesday, October 31, 2017 4:01 PM To: Hubert Tong Cc: Zachary Turner via llvm-dev Subject: Re: [llvm-dev] Using C++14 code in LLVM On Tue, Oct 31, 2017 at 3:45 PM Hubert Tong <hubert.reinterpretcast at gmail.com<mailto:hubert.reinterpretcast at gmail.com>> wrote: On Tue, Oct 31, 2017 at 6:26 PM, Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: On Tue, Oct 31, 2017 at 3:19 PM Justin Bogner <mail at justinbogner.com<mailto:mail at justinbogner.com>> wrote: Zachary Turner <zturner at google.com<mailto:zturner at google.com>> writes:> If 3 months later we started requiring C++17, someone could build clang 6 > with the system compiler and then build Clang ToT. > > If 3 months later we started requiring C++20, someone could still build > clang 6 with the system compiler and then build Clang ToT. > > Every relaxation of the kind of code we can use in LLVM does not > necessitate an extra hop in the bootstrapping process, because existing > versions of clang can already compile through C++20.The feature set of C++20 is not closed yet by the committee. I don't see where this is coming from (but if you would like to share, then please do tell). I hate to exaggerate, but this sounds almost like an argument for using new C++ features the day after we implement them. There obviously has to be some balance here. Someone could probably use that line of reasoning to argue for using new features immediately after implementing them, but that someone wouldn't be me :) In any case, the point was simply to illustrate that, in general, you do not need to add a hop to the bootstrapping process every time you bump the language standard. C++20 is 4-6 years out before we're even discussing it though, and any discussion we have about if, when, or how to move to it now will probably be irrelevant by that time. For C++14 and C++17 though, I think the argument still holds. System Compiler -> {GCC 7 or Clang 5-6} -> ToT Copies of C++17 are not available for sale yet. There will likely be tweaks in the wording and in the implementation. It would be quite unfortunate to pick up C++17 for development on ToT only to discover 3 years afterwards that some range of revisions can only be built properly with some specific build compilers with a particular bug/interpretation of the feature. Technically correct (the best kind). But I don't have a CL up for review that I'm waiting to commit which changes the standard, nor am I even proposing moving to C++17 in the immediate future (indeed, in the original post I mentioned at least one compiler does not have *any* feature complete C++17 implementation available, and is actually a ways out from having one, and certainly we couldn't consider adopting C++17 until every supported compiler has *some* version that is feature complete). C++14 is a different story, and that was part of the reason for the original post. There is definitely interest from many people to at least --have a plan-- for bumping the standard. So the goal of this is to work this plan out. With MSVC we have a very clear, tangible policy of "we support the two latest major releases of MSVC". This is what I'm trying to get at. ---What is the policy for GCC?--- It seems like we don't have one. I would like to have an actual, concrete, specific, well-defined rule that people can refer to decide when we can bump the minimum required GCC version. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171101/61b71339/attachment-0001.html>