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

Sat May 12 20:43:12 PDT 2018

Minor note on process for these types of discussions....

When proposing we move to a new language version, it would be very 
helpful if you could take the time to identify the specific minimal 
compiler version required and the minimal distro version which supports 
that toolchain for each of the major distros.  For those of us which 
ship software using LLVM, that's the mapping we really need to decide 
whether a proposed upgrade is an issue or not.

For instance, I can probably upgrade to any compiler easily buildable on 
REHL6, but likely *can not* upgrade to any compile not buildable on REHL6.

Having this up front saves a lot of research and makes the discussion a 
lot easier internally.

Thanks.

Philip

On 05/10/2018 10:01 AM, JF Bastien via llvm-dev 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 
> <http://apple.com>> wrote:
> >
> >>
> >> On Oct 4, 2016, at 2:10 PM, Reid Kleckner <rnk at google.com 
> <http://google.com>> wrote:
> >>
> >> On Tue, Oct 4, 2016 at 11:58 AM, Mehdi Amini <mehdi.amini at 
> apple.com <http://apple.com>>
> >> wrote:
> >>
> >>>
> >>> On Oct 4, 2016, at 8:40 AM, Reid Kleckner via llvm-dev <
> >>> llvm-dev at lists.llvm.org <http://lists.llvm.org>> wrote:
> >>>
> >>> On Tue, Oct 4, 2016 at 8:29 AM, Zachary Turner <zturner at 
> google.com <http://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/20180512/597c952e/attachment.html>