[llvm-dev] Using C++14 code in LLVM

[Zachary Turner via llvm-dev]

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>