> 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 <mailto: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 <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> On Tue, Oct 4, 2016 at 8:29 AM, Zachary Turner <zturner at google.com <mailto: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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161004/0e1d0603/attachment.html>
On Tue, Oct 31, 2017 at 1:57 PM, Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote:> 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. >The existence of the newer version of LTS doesn't matter for those who are using older, but supported LTS, because it is supported. We cannot say to them that it is end of life so they should upgrade. That said, newer compilers are just one command away on Ubuntu 14.04 LTS. If I'm interpreting this page correctly https://packages.ubuntu.com/trusty/devel/, you can install any version of Clang between 3.3 to 3.9 using apt-get, and I don't think doing that is too much hassle. 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/20171031/b3116e07/attachment.html>
Note that we could, in theory, provide a python script or something called `bootstrap.py` which a) downloads a source tarball, or specific git revision for a particular clang release b) compiles it using system compiler c) installs it d) cleans up so that you wouldn't have to do anything manually. The script could early-out if it detects a recent enough compiler version so that bootstrapping was unnecessary. I think this would hide much of the complexity about having to deal with getting a modern toolchain, so that the workflow would be: 1) check out LLVM ToT 2) run bootstrap.py 3) build -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171031/bf09e242/attachment.html>
On Tue, Oct 31, 2017 at 11:57 PM, Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote:> 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. >7.1's been out since May, and 7.2 since August. Ought to be stable. 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. >I don't understand the issue here. Sure it's rude to replace the system compiler, in case something three years old that should build suddenly doesn't. But that's absolutely no reason to not build a newer version in a user's working directory and use it from there. Tons of projects do that. I believe even gcc 7.2 only needs a C++98 compiler in order to build. 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. >Same comment. 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. >Seems reasonable. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171101/ac908af1/attachment.html>
On 31.10.2017 21:57, Zachary Turner via llvm-dev wrote:> 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. >NetBSD ships with GCC-4.8.x in NetBSD-7 and GCC-5.x in NetBSD-8. NetBSD 8.0 should be released soon (this year?). This is just the base compiler. We ship newer and older versions in pkgsrc for any stable release. The most recent is gcc8snapshot from 20171022, the oldest one is gcc2. GCC from pkgsrc does not conflict with the base system and people can install simultaneously any number of them. I expect that someone might be upset to use an intermediate bootstrap compiler, but as long as no need for this in the most recent version (8.0beta with GCC 5.4.0) I think it's fine. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171031/44b3d340/attachment.sig>
Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> writes:> 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)I don't think any of these are compelling enough to push us to upgrade.> > 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.These are all nice, but are they worth the cost at this point?> > 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.If we want to enable C++17 we need clang 5.0, which was released less than two months ago.> 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.We shouldn't make people bootstrap the compiler without a very good reason. I really don't want to be in the situation where you have to get clang 3.7 to bootstrap 5.0 to bootstrap 7.0 to bootstrap 9.0 in 2019.> 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.I don't understand how this argument holds. If we change the minimum c++ standard we build with every time one comes out, we'll definitely have a long daisy chain of compilers that need to be built to start working on LLVM at all.> * 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 10/31/2017 01:57 PM, Zachary Turner via llvm-dev wrote:> 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?) >On CentOS & RHEL, Red Hat Developer Toolset[1] provides newer versions of gcc that can be installed alongside the system gcc. The most recent version, devtoolset-7, has gcc 7.2.1, so CentOS & RHEL, so CentOS and RHEL should be fine with more modern C++ code. -Tom [1] https://developers.redhat.com/products/developertoolset/overview/> 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 <mailto:mehdi.amini at apple.com>> wrote: > > >> On Oct 4, 2016, at 2:10 PM, Reid Kleckner <rnk at google.com <mailto:rnk at google.com>> wrote: >> >> On Tue, Oct 4, 2016 at 11:58 AM, Mehdi Amini <mehdi.amini at apple.com <mailto: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 <mailto:llvm-dev at lists.llvm.org>> wrote: >>> >>> On Tue, Oct 4, 2016 at 8:29 AM, Zachary Turner <zturner at google.com <mailto: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 >
Hi Zachary, One important thing should be taken into account when a compiler supporting C++14 or higher is put on the requirements list. The process of migration to new versions of OSes/compilers at companies building LLVM-based products is not fast. It might take months. I still remember that moving from gcc4.7.x to gcc4.9.x to build LLVM on our build servers took a lot of time. I hope moving to GCC5 will be less painful. Thanks, Evgeny From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> Reply-To: Zachary Turner <zturner at google.com> Date: Tuesday, 31 October 2017 at 20:58 To: Mehdi Amini <mehdi.amini at apple.com> Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] Using C++14 code in LLVM 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<mailto:mehdi.amini at apple.com>> wrote: On Oct 4, 2016, at 2:10 PM, Reid Kleckner <rnk at google.com<mailto:rnk at google.com>> wrote: On Tue, Oct 4, 2016 at 11:58 AM, Mehdi Amini <mehdi.amini at apple.com<mailto: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<mailto:llvm-dev at lists.llvm.org>> wrote: On Tue, Oct 4, 2016 at 8:29 AM, Zachary Turner <zturner at google.com<mailto: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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171031/f94cf774/attachment.html>
> Date: Tue, 31 Oct 2017 20:57:45 +0000 > From: Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> > > 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.1OpenBSD 6.2 shipped with LLVM/Clang 4.0.0 and OpenBSD 6.3 will ship with at least LLVM/Clang 5.0.0 as the system compiler on amd64, arm64 and i386. We're planning to switch armv7 over as well, and may provide Clang alongside GCC for mips64 and sparc64 as well. So for us a more relevant question is whether Clang 4 or Clang 5 has sufficient C++14/17 support.