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

Thu May 10 11:49:43 PDT 2018

The easy way not to have a three year discussion is to not worry about it
for another three years. :)

So, I think we should take the easy things on the table and just move to
C++14 in the near future. It's just a matter of dropping support for
building on distros that only have GCC <5 (aka Trusty, which is from 2014
itself). Let's do that and call it a day.

---
Aside: I'm always kind of amused by talk of moving to the next "standard
version" when the reality is that every C++ project is always held back by
the compilers and standard libraries that they actually use in practice. We
say LLVM requires C++11 which mandates a working set of threading
primitives, but in practice those don't exist on some platforms that people
would like us to support, so we end up maintaining the
LLVM_ENABLE_THREADING=0 build for them.

It seems more practical to simply list the minimum versions of supported
toolchains that are commonly used to build, i.e. GCC 5, MSVC 2015, Clang
3.N, libc++ 3.N, libstdc++ 3.N, etc.

On Thu, May 10, 2018 at 11:36 AM Zachary Turner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> If it's the only thing we can agree then I'll take it, but I just worry
> that 3 years from now we're going to start another 3 year discussion, so
> that any actual move to C++17 would end up taking double the time.
>
> Are the issues specific to C++17 additions to the standard library?  What
> if you allow C++17 language features but not C++17 library features?  I'm
> guessing this is too simple though and isn't sufficient to avoid the
> problems (which I don't know anything about, so you'll have to enlighten
> me)?
>
> On Thu, May 10, 2018 at 11:28 AM JF Bastien <jfbastien at apple.com> wrote:
>
>>
>> On May 10, 2018, at 11:22 AM, Zachary Turner <zturner at google.com> wrote:
>>
>> Windows has never been the issue.  Honestly, MSVC on Windows is "fully
>> C++17 conformant" [1].
>>
>> The issue has and always will be GCC.  Given that a bump in any version
>> of GCC has been (and will remain) difficult for some time, I propose that
>> we skip C++14 and move to 17.  We don't want to have a multi-year
>> disccusion about this again any time soon, and from what I gather, nobody
>> has any more reservations about moving to C++17 than they do about moving
>> to C++14.  They only have reservations about moving to anything at all.  So
>> if we're gonna move, we should go all the way.
>>
>>
>> WebKit’s move to C++17 hasn’t been super smooth because of GCC /
>> libstdc++ issues in both GCC 6 and GCC 7. It’s all fixable, but given
>> LLVM's slow move out of C++11 I’d rather get C++14 now rather than a
>> painful transition to C++17 that drags on as we discover issues.
>>
>>
>> Just my 2c.
>>
>> [1]
>> https://blogs.msdn.microsoft.com/vcblog/2018/05/07/announcing-msvc-conforms-to-the-c-standard/
>>
>> On Thu, May 10, 2018 at 11:18 AM Eric Christopher <echristo at gmail.com>
>> wrote:
>>
>>> Once again, I'm totally down for this and think we should do it. I worry
>>> about windows, but ...
>>>
>>> Zach: How's windows c++14 support looking?
>>>
>>> -eric
>>>
>>> On Thu, May 10, 2018 at 10:01 AM JF Bastien via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>> Hi folks!
>>>>
>>>> Six more months have come and gone, and maybe we could move LLVM to
>>>> C++14 now?
>>>>
>>>> The issues I picked out from the last discussion:
>>>>
>>>>    1. Some folks want an official policy about compiler support before
>>>>    updating the standard version we use.
>>>>    2. Worries about which GCC version is available in which distro.
>>>>    3. Worries about MSVC.
>>>>
>>>>
>>>> Instead of rehashing the compiler per distro surveys from previous
>>>> discussion, and instead of talking bootstrap, let me offer three data
>>>> points:
>>>>
>>>>    - WebKit is moving to C++17
>>>>    <https://lists.webkit.org/pipermail/webkit-dev/2018-March/029922.html> (from
>>>>    C++14) right now †
>>>>    - Chromium started moving to C++14
>>>>    <https://groups.google.com/a/chromium.org/d/msg/cxx/ow7hmdDm4yw/eV6KWL2yAQAJ> in
>>>>    August of last year
>>>>    - Firefox uses some C++14
>>>>    <https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code>
>>>>
>>>> What I get from this data: if your distro bundles a modern web browser,
>>>> it already builds some C++14, *somehow*.
>>>>
>>>> The LLVM community has been talking about this for a while now, and I’m
>>>> not aware of a policy coming to light. I don’t think we need a policy given
>>>> the above data. So how about we… just kinda... move LLVM to C++14?
>>>>
>>>>
>>>> Thanks!
>>>>
>>>> JF
>>>>
>>>>
>>>> † the move to C++17 is very painful, but 14 has been working great in
>>>> WebKit for quite a long time.
>>>>
>>>>
>>>> > 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)
>>>> >
>>>> >
>>>> > 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.
>>>> >
>>>> >
>>>> > 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.
>>>> >
>>>> > 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.
>>>> >
>>>> >
>>>> > 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.
>>>> >
>>>> > * 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 4, 2016 at 2:15 PM Mehdi Amini <mehdi.amini at apple.com>
>>>> wrote:
>>>> >
>>>> >>
>>>> >> On Oct 4, 2016, at 2:10 PM, Reid Kleckner <rnk at google.com> wrote:
>>>> >>
>>>> >> On Tue, Oct 4, 2016 at 11:58 AM, Mehdi Amini <mehdi.amini at
>>>> apple.com>
>>>> >> wrote:
>>>> >>
>>>> >>>
>>>> >>> On Oct 4, 2016, at 8:40 AM, Reid Kleckner via llvm-dev <
>>>> >>> llvm-dev at lists.llvm.org> wrote:
>>>> >>>
>>>> >>> On Tue, Oct 4, 2016 at 8:29 AM, Zachary Turner <zturner at
>>>> google.com>
>>>> >>> wrote:
>>>> >>>>
>>>> >>>> I ask because many of these LTS distros are notoriously slow at
>>>> updating
>>>> >>>> their packages. While some people may think C++14 doesn't provide
>>>> enough
>>>> >>>> bang for the buck to justify bumping to GCC 4.9, C++17 definitely
>>>> does. But
>>>> >>>> at that point we're going to be talking about GCC 6.1 or 6.2,
>>>> which is
>>>> >>>> going to be significantly harder unless we want to wait 5-7 years,
>>>> and I
>>>> >>>> suspect people won't.
>>>> >>>>
>>>> >>>
>>>> >>> If by "notoriously slow" you mean they don't bump their toolchain
>>>> >>> versions at all, then yeah. We just wait until the LTS release is at
>>>> >>> end-of-life before dropping it.
>>>> >>>
>>>> >>>
>>>> >>> That’s the first time I read about this policy: we support every
>>>> linux
>>>> >>> LTS distribution till their end-of-life? Only Ubuntu? Do you have a
>>>> pointer
>>>> >>> where it is documented / discussed?
>>>> >>> (Note that Ubuntu LTS is 5 years AFAIK.)
>>>> >>>
>>>> >>
>>>> >> Sorry, I didn't mean to refer to the LTS support lifetime. I just
>>>> meant we
>>>> >> support the last LTS until we can reasonably expect users to have
>>>> upgraded
>>>> >> to the new one. If there's an LTS release every two years, then we
>>>> want to
>>>> >> keep supporting them for at least three years to give people a year
>>>> to
>>>> >> upgrade.
>>>> >>
>>>> >>
>>>> >> OK, got it.
>>>> >>
>>>> >> Thanks for clarifying!
>>>> >>
>>>> >> Mehdi
>>>> >>
>>>> >>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>> _______________________________________________
> 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/20180510/caf4a5d5/attachment.html>