[llvm-dev] Using C++14 code in LLVM
JF Bastien via llvm-dev
llvm-dev at lists.llvm.org
Fri May 11 09:16:25 PDT 2018
> On May 11, 2018, at 4:36 AM, Dimitry Andric <dimitry at andric.com> wrote:
>
> 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.
I initially proposed 3.4 because it has ~all C++14 language features (albeit under std=c++1y), but someone on the patch asked for 3.5 so the flags would be simpler. Your use case seems to outweigh the one made about simplicity of flags.
One thing I still want to check is how buggy each compiler’s support for C++14 is. We can mandate 3.4 all we want, but if it mishandles C++14 features we’re much worst off.
For reference, the patch is https://reviews.llvm.org/D46723 <https://reviews.llvm.org/D46723>
> -Dimitry
>
>> On 10 May 2018, at 22:50, Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org <mailto: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 <mailto: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/4bdf006f/attachment-0001.html>
More information about the llvm-dev
mailing list