llvm dev - Oct 2017 - Using C++14 code in LLVM

Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org>
writes:
> Last time we discussed this, the consensus was "I think we can survive
> another year without generalized constexpr and variable templates".
>
> Well, we did indeed survive.   And it's been exactly a year!  So
naturally,
> it only makes sense to revive this :)
>
>
>
> There's an active conversation going on in IRC right now, and it seems
like
> there is more desire than there was last year.
>
> What are the main gains from allowing C++14?
> * Variable templates
> * Generalized constexpr
> * Return-type Deduction
> * Generic Lambdas
> * std::make_unique<> (the source of many build bot breakages)
I don't think any of these are compelling enough to push us to upgrade.
>
> What are the main gains from allowing C++17?  [1]
> * [[nodiscard]] attribute
> * structured bindings
> * constexpr-if
> * guaranteed copy elision
> * numerous new library types: optional, string_view, variant, byte,
> * numerous new algorithms: parallel algorithms, too many to list
> * Probably some more, but I just tried to hit the biggest ones.
These are all nice, but are they worth the cost at this point?
>
> First, it seems like if we want to enable C++14 we need GCC >= 5.
> And if we want to enable C++17 we need GCC >= 7.
If we want to enable C++17 we need clang 5.0, which was released less
than two months ago.
> With that out of the way, here were some of the issues that were raised
> last time:
>
> Issue: Ubuntu 14.04 LTS is on GCC 4.8.x, and we have to support it until
> end of life.
> Resolution: LTS is right around the corner, in 6 more months.
>
> Issue: Various other platforms have older GCCs as their system compiler,
> and it's annoying to upgrade.
> Question: Do any of these not have a port you can install?  For example,
> NetBSD 7 appears to have GCC 5.3 as a port, if DistroWatch is any
> indication.  It could be wrong though and I could also be misinterpreting
> it.
>
> Issue: If we're going to make people bootstrap a compiler, we might as
well
> go all the way to C++17.
> Comment: I'm not opposed.
We shouldn't make people bootstrap the compiler without a very good
reason. I really don't want to be in the situation where you have to get
clang 3.7 to bootstrap 5.0 to bootstrap 7.0 to bootstrap 9.0 in 2019.
> Some questions / comments of my own:
>
> * Where is this policy about Ubuntu and LTS documented?  Does this mean,
> for example, that we will not be able to use C++17 until 2023 (16.04 LTS
> has only GCC 5.3.1)?  That seems a bit unreasonable.  And there's no
> guarantee that 18.04 LTS will even have GCC 7 or higher either, so it could
> be 2025 or 2027.
>
> * We've asked people in the past to build a modern toolchain.  For
example,
> we did it with C++11 and Ubuntu 12.04 LTS.  Is C++17 compelling enough to
> justify this again?
>
> * GCC 4.9 probably isn't sufficient to justify an increase for anyone,
as
> it lacks two of the more sought-after features of C++14 (variable templates
> and generalized constexpr).  So IMO we should require a bump to GCC 5 or
> higher, or not at all.
>
> * Clang 6 supports all of C++20, and it builds with only C++11, so we
> shouldn't have to worry too much about the problem of needing to
"daisy
> chain" compilers to finally get the latest version of LLVM building. 
"GCC
> 4.8 -> Clang 6 - > Clang ToT" should hold up through C++1z.
I don't understand how this argument holds. If we change the minimum c++
standard we build with every time one comes out, we'll definitely have a
long daisy chain of compilers that need to be built to start working on
LLVM at all.
> * While we obviously can't be tied to the versioning of every single
distro
> out there, some are "bigger" than others.  Which are big enough
that
> warrant serious consideration?  The ones I found are (and I did my best to
> aggregate all this, but please correct me if anything is incorrect or
> misrepresented):
>
> OpenBSD - Ships with GCC 4.2.1 anyway.  They are already having to
> bootstrap something, so the proposal here does not change anything, because
> even current LLVM doesn't compile with GCC 4.2.1
>
> CentOS & RHEL - No version of Distro, including trunk, has GCC >=
4.8.5
> (are there ports?)
>
> Debian - Minimum version 9 for GCC >= 5  (are there ports for earlier
> releases?)
>
> Fedora - Minimum version 24 for GCC >= 5, minimum version 26 for GCC
>= 7
>
> Ubuntu - Minimum LTS 16.04 for GCC >= 5
>
> NetBSD - Version 7 has GCC 4.8.4 by default, but contains port for 5.3.0
>
> FreeBSD - Minimum Version 11 for GCC >= 5
>
> So, thoughts?
>
>
> [1] - Note that we'd need to wait a few more revs for MSVC before
allowing
> C++17, but given that it's becoming easier and easier to bump the
minimum
> MSVC version, I'm discounting this as a factor, as MSVC will not really
be
> the bottleneck in any real sense.

On Tue, Oct 31, 2017 at 2:45 PM Justin Bogner <mail at justinbogner.com>
wrote:
> Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> writes:
> >
> > Issue: If we're going to make people bootstrap a compiler, we
might as
> well
> > go all the way to C++17.
> > Comment: I'm not opposed.
>
> We shouldn't make people bootstrap the compiler without a very good
> reason. I really don't want to be in the situation where you have to
get
> clang 3.7 to bootstrap 5.0 to bootstrap 7.0 to bootstrap 9.0 in 2019.
>
Why would this many hops ever be necessary?  System Compiler -> {Clang 5 or
GCC 7} -> Clang ToT should be sufficient to last until C++23, which we
probably wouldn't adopt until 2025-2030 anyway

>
> > * Clang 6 supports all of C++20, and it builds with only C++11, so we
> > shouldn't have to worry too much about the problem of needing to
"daisy
> > chain" compilers to finally get the latest version of LLVM
building.
> "GCC
> > 4.8 -> Clang 6 - > Clang ToT" should hold up through C++1z.
>
> I don't understand how this argument holds. If we change the minimum
c++
> standard we build with every time one comes out, we'll definitely have
a
> long daisy chain of compilers that need to be built to start working on
> LLVM at all.
>
Clang 6 supports all of C++20.  If we started requiring C++14 today,
someone can build Clang 6 with the system compiler and then build Clang ToT.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171031/7598cd9f/attachment.html>

> On 1 Nov 2017, at 08:56, Zachary Turner via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 
> 
> On Tue, Oct 31, 2017 at 2:45 PM Justin Bogner <mail at justinbogner.com
<mailto:mail at justinbogner.com>> wrote:
> Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org
<mailto:llvm-dev at lists.llvm.org>> writes:
> >
> > Issue: If we're going to make people bootstrap a compiler, we
might as well
> > go all the way to C++17.
> > Comment: I'm not opposed.
> 
> We shouldn't make people bootstrap the compiler without a very good
> reason. I really don't want to be in the situation where you have to
get
> clang 3.7 to bootstrap 5.0 to bootstrap 7.0 to bootstrap 9.0 in 2019.
> 
> Why would this many hops ever be necessary?  System Compiler -> {Clang 5
or GCC 7} -> Clang ToT should be sufficient to last until C++23, which we
probably wouldn't adopt until 2025-2030 anyway
>  
Can this be fixed by automation though?

I mean, a script can determine what the system compiler is, and determine which
minimal versions of the toolchain (frontend, linker, etc.) in which order to be
able to build the latest compiler that uses C++17. Seems like a fixable problem.

Ideally you only need to do this once, and normal development will allow you to
use the "known good" bootstrap compiler.
> 
> > * Clang 6 supports all of C++20, and it builds with only C++11, so we
> > shouldn't have to worry too much about the problem of needing to
"daisy
> > chain" compilers to finally get the latest version of LLVM
building.  "GCC
> > 4.8 -> Clang 6 - > Clang ToT" should hold up through C++1z.
> 
> I don't understand how this argument holds. If we change the minimum
c++
> standard we build with every time one comes out, we'll definitely have
a
> long daisy chain of compilers that need to be built to start working on
> LLVM at all.
> Clang 6 supports all of C++20.  If we started requiring C++14 today,
someone can build Clang 6 with the system compiler and then build Clang ToT.
> 
> 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.
Not only this, but if we ever needed to do something different later on,
automation can take care of adding the correct intermediate steps.

Needless to say, I'm in favour of switching the default to C++17, FWIW.

Cheers

-- Dean

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171101/af3f1768/attachment.html>

Zachary Turner <zturner at google.com> writes:
> On Tue, Oct 31, 2017 at 2:45 PM Justin Bogner <mail at
justinbogner.com> wrote:
>
>> Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> writes:
>> >
>> > Issue: If we're going to make people bootstrap a compiler, we
might as
>> well
>> > go all the way to C++17.
>> > Comment: I'm not opposed.
>>
>> We shouldn't make people bootstrap the compiler without a very good
>> reason. I really don't want to be in the situation where you have
to get
>> clang 3.7 to bootstrap 5.0 to bootstrap 7.0 to bootstrap 9.0 in 2019.
>>
>
> Why would this many hops ever be necessary?  System Compiler -> {Clang 5
or
> GCC 7} -> Clang ToT should be sufficient to last until C++23, which we
> probably wouldn't adopt until 2025-2030 anyway
There is no compiler today that accepts the "-std=c++20" flag,
regardless of how much of c++20 they (are likely to) support. There are
also presumably some bugs, so I think this claim is a bit disingenuous.
>>
>> > * Clang 6 supports all of C++20, and it builds with only C++11, so
we
>> > shouldn't have to worry too much about the problem of needing
to "daisy
>> > chain" compilers to finally get the latest version of LLVM
building.
>> "GCC
>> > 4.8 -> Clang 6 - > Clang ToT" should hold up through
C++1z.
>>
>> I don't understand how this argument holds. If we change the
minimum c++
>> standard we build with every time one comes out, we'll definitely
have a
>> long daisy chain of compilers that need to be built to start working on
>> LLVM at all.
>>
> Clang 6 supports all of C++20.  If we started requiring C++14 today,
> someone can build Clang 6 with the system compiler and then build Clang
ToT.
C++20 doesn't exist yet. Clang 6 supports something that is very close
to what C++20 will be. Also, Clang 6 *is* Clang ToT right now, so I
think you mean they could build Clang 5 and then build Clang ToT.
> 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.
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.

On Tue, Oct 31, 2017 at 02:45:24PM -0700, Justin Bogner via llvm-dev
wrote:
> We shouldn't make people bootstrap the compiler without a very good
> reason. I really don't want to be in the situation where you have to
get
> clang 3.7 to bootstrap 5.0 to bootstrap 7.0 to bootstrap 9.0 in 2019.
That is even ignoring the case of using LLVM as a library. Mixing GCC
versions is painful and can create all kinds of ABI fun. LLVM is not
just a single binary named clang.

Joerg