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

[Justin Bogner via llvm-dev]

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.