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

Thu May 10 13:50:28 PDT 2018

Last time this came up, there were a lot of people that were stuck on GCC
4.9 due to ABI reasons. I think forcing that upgrade is going to be the
most disruptive part of this, and I think that will really need a decent
amount of time. =[

On Thu, May 10, 2018 at 2:26 PM JF Bastien via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
> On May 10, 2018, at 12:25 PM, Evgeny Astigeevich via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hi,
>
> IMHO, it’s a good idea to move to C++14 first.
>
> What do you think about doing this by two phases:
>
> Phase1: require GCC >= 5 but build in C++11 mode (this will give time to
> adapt build infrastructure to a new gcc)
> Phase2: switch to C++14
>
>
> Sounds reasonable, here’s a patch:
> https://reviews.llvm.org/D46723
>
>
> Thanks,
> Evgeny
>
>
>
> *From: *llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Reid
> Kleckner via llvm-dev <llvm-dev at lists.llvm.org>
> *Reply-To: *Reid Kleckner <rnk at google.com>
> *Date: *Thursday, 10 May 2018 at 19:50
> *To: *Zachary Turner <zturner at google.com>
> *Cc: *llvm-dev <llvm-dev at lists.llvm.org>
> *Subject: *Re: [llvm-dev] Using C++14 code in LLVM
>
> 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
>
> _______________________________________________
> 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/56c838c6/attachment.html>