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

Thu May 10 11:35:42 PDT 2018

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