<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 31, 2017 at 3:45 PM Hubert Tong <<a href="mailto:hubert.reinterpretcast@gmail.com">hubert.reinterpretcast@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 31, 2017 at 6:26 PM, Zachary Turner via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 31, 2017 at 3:19 PM Justin Bogner <<a href="mailto:mail@justinbogner.com" target="_blank">mail@justinbogner.com</a>> wrote:<br></div><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> writes:<br><br>
> If 3 months later we started requiring C++17, someone could build clang 6<br>
> with the system compiler and then build Clang ToT.<br>
><br>
> If 3 months later we started requiring C++20, someone could still build<br>
> clang 6 with the system compiler and then build Clang ToT.<br>
><br>
> Every relaxation of the kind of code we can use in LLVM does not<br>
> necessitate an extra hop in the bootstrapping process, because existing<br>
> versions of clang can already compile through C++20.<br></blockquote></span></div></div></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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).<br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I hate to exaggerate, but this sounds almost like an argument for using<br>
new C++ features the day after we implement them. There obviously has to<br>
be some balance here.<br></blockquote><div><br></div></span>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 :)<br><div><br></div><div>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.</div><div><br></div><div>For C++14 and C++17 though, I think the argument still holds.  System Compiler -> {GCC 7 or Clang 5-6} -> ToT</div></div></div></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.<br></div><div> </div></div></div></div></blockquote><div><br></div><div> 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).</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>---What is the policy for GCC?---</div><div><br></div><div>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.</div></div></div>