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. 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 >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180510/b2db10f6/attachment.html>
> 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/ <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: > Some folks want an official policy about compiler support before updating the standard version we use. > Worries about which GCC version is available in which distro. > 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>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180510/3ecb6e61/attachment.html>
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 >>> >>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180510/12754db4/attachment.html>
On Thu, May 10, 2018 at 11:23 AM Zachary Turner <zturner at google.com> wrote:> Windows has never been the issue. Honestly, MSVC on Windows is "fully > C++17 conformant" [1]. > >My worries were mostly "I don't know" :)> 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. > > 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 >>> >>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180510/4513eb6d/attachment-0001.html>