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

Sun May 13 11:35:39 PDT 2018

The Red Hat Developer Toolset supports gcc 7 on RHEL 6.7 or later. The
builds it produces are ABI compatible with the rest of the system. This
does mean the library is not 100% conformant, using for example, the old
COW string rather than SSO.

Some detail:
https://access.redhat.com/documentation/en-us/red_hat_developer_toolset/7/html/user_guide/chap-red_hat_developer_toolset#sect-Red_Hat_Developer_Toolset-Compatibility

On Sun, May 13, 2018 at 12:52 AM Bruce Hoult via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> As you probably know, RHEL6 comes with gcc 4.4.7, which doesn't even
> support C++11. You can install gcc 6.3.1 from Red Hat Software Collections,
> and that fully supports C++11 and C++14, but not 17.
>
> On Sun, May 13, 2018 at 3:43 PM, Philip Reames via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> 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>
>> 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 listllvm-dev at lists.llvm.orghttp://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/20180513/cb826228/attachment-0001.html>