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

Dimitry Andric via llvm-dev llvm-dev at lists.llvm.org
Fri May 11 04:36:04 PDT 2018 

And what will be the lowest version of clang that will be supported for building?  FreeBSD's oldest supported OS release is still stuck with clang 3.4 (and a corresponding copy of libc++), which has some support for C++14, although it's still called c++1y there, but probably not C++17.  Also, it isn't exactly clear from which llvm/clang release C++17 is fully supported.

-Dimitry

> On 10 May 2018, at 22:50, Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> 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 <mailto: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 <mailto: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 <https://reviews.llvm.org/D46723>
> 
> 
>> Thanks,
>> Evgeny
>> 
>> 
>> 
>> From: llvm-dev <llvm-dev-bounces at lists.llvm.org <mailto:llvm-dev-bounces at lists.llvm.org>> on behalf of Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
>> Reply-To: Reid Kleckner <rnk at google.com <mailto:rnk at google.com>>
>> Date: Thursday, 10 May 2018 at 19:50
>> To: Zachary Turner <zturner at google.com <mailto:zturner at google.com>>
>> Cc: llvm-dev <llvm-dev at lists.llvm.org <mailto: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 <mailto: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 <mailto:jfbastien at apple.com>> wrote:
>>>> 
>>>> 
>>>>> On May 10, 2018, at 11:22 AM, Zachary Turner <zturner at google.com <mailto: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/ <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 <mailto: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 <mailto: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 <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 <mailto:llvm-dev at lists.llvm.org>
>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>_______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <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/20180511/d579bb84/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 223 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180511/d579bb84/attachment.sig>

More information about the llvm-dev mailing list