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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Adam Nemet via llvm-dev
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:
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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Adam Nemet via llvm-dev
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 <[hidden email]> 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:
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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Adam Nemet via llvm-dev
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.


On Thu, May 10, 2018 at 11:18 AM Eric Christopher <[hidden email]> 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 <[hidden email]> 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:
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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Adam Nemet via llvm-dev


On May 10, 2018, at 11:22 AM, Zachary Turner <[hidden email]> 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.



On Thu, May 10, 2018 at 11:18 AM Eric Christopher <[hidden email]> 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 <[hidden email]> 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:
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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Adam Nemet via llvm-dev
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 <[hidden email]> wrote:

On May 10, 2018, at 11:22 AM, Zachary Turner <[hidden email]> 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.



On Thu, May 10, 2018 at 11:18 AM Eric Christopher <[hidden email]> 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 <[hidden email]> 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:
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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Adam Nemet via llvm-dev
In reply to this post by Adam Nemet via llvm-dev


On Thu, May 10, 2018 at 11:23 AM Zachary Turner <[hidden email]> 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.


On Thu, May 10, 2018 at 11:18 AM Eric Christopher <[hidden email]> 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 <[hidden email]> 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:
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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Adam Nemet via llvm-dev
In reply to this post by Adam Nemet via llvm-dev
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 <[hidden email]> 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 <[hidden email]> wrote:

On May 10, 2018, at 11:22 AM, Zachary Turner <[hidden email]> 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.



On Thu, May 10, 2018 at 11:18 AM Eric Christopher <[hidden email]> 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 <[hidden email]> 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:
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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Adam Nemet via llvm-dev
In reply to this post by Adam Nemet via llvm-dev


On May 10, 2018, at 11:35 AM, Zachary Turner <[hidden email]> 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.

Such a fatalistic view, let’s trust ourselves to be better next time ;-)
But seriously: we can learn from moving to C++14, and use what we’ve learned to move to C++17 faster next time. Also consider the code churn we’ll encounter as we fix incompatibilities with C++11 / C++14, drop unnecessary code, upgrade various uses, that will happen regardless of moving to C++17 and will take a little while to occur. There would be more of that type of churn if we went straight to C++17.


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)?

Mostly library so far, yes, but the GCC 6 support for C++17 language isn’t great either:

 - New auto rules for direct-list-initialization
 - static_assert with no message
 - typename in a template template parameter
 - Nested namespace definition
 - Attributes for namespaces and enumerators
 - u8 character literals
 - Allow constant evaluation for all non-type template arguments
 - Fold Expressions
 - Unary fold expressions and empty parameter packs
 - __has_include in preprocessor conditional
 - Differing begin and end types in range-based for\


The only thing that’s really nice are fold expressions, and I hope they’re not buggy in GCC 6.

Otherwise the list is missing a good amount for C++17 language features, and brings up the discussion of which GCC version is the minimum we mandate. I’d rather avoid that discussion. Let’s assume GCC 6, if we get 7 then great, but it doesn’t matter if we stick to C++14.


On Thu, May 10, 2018 at 11:28 AM JF Bastien <[hidden email]> wrote:

On May 10, 2018, at 11:22 AM, Zachary Turner <[hidden email]> 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.



On Thu, May 10, 2018 at 11:18 AM Eric Christopher <[hidden email]> 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 <[hidden email]> 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:
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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Adam Nemet via llvm-dev
Consider me on board with the highest version we can come to an agreement on :)


On Thu, May 10, 2018 at 11:50 AM JF Bastien <[hidden email]> wrote:

On May 10, 2018, at 11:35 AM, Zachary Turner <[hidden email]> 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.

Such a fatalistic view, let’s trust ourselves to be better next time ;-)
But seriously: we can learn from moving to C++14, and use what we’ve learned to move to C++17 faster next time. Also consider the code churn we’ll encounter as we fix incompatibilities with C++11 / C++14, drop unnecessary code, upgrade various uses, that will happen regardless of moving to C++17 and will take a little while to occur. There would be more of that type of churn if we went straight to C++17.


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)?

Mostly library so far, yes, but the GCC 6 support for C++17 language isn’t great either:

 - New auto rules for direct-list-initialization
 - static_assert with no message
 - typename in a template template parameter
 - Nested namespace definition
 - Attributes for namespaces and enumerators
 - u8 character literals
 - Allow constant evaluation for all non-type template arguments
 - Fold Expressions
 - Unary fold expressions and empty parameter packs
 - __has_include in preprocessor conditional
 - Differing begin and end types in range-based for\


The only thing that’s really nice are fold expressions, and I hope they’re not buggy in GCC 6.

Otherwise the list is missing a good amount for C++17 language features, and brings up the discussion of which GCC version is the minimum we mandate. I’d rather avoid that discussion. Let’s assume GCC 6, if we get 7 then great, but it doesn’t matter if we stick to C++14.


On Thu, May 10, 2018 at 11:28 AM JF Bastien <[hidden email]> wrote:

On May 10, 2018, at 11:22 AM, Zachary Turner <[hidden email]> 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.



On Thu, May 10, 2018 at 11:18 AM Eric Christopher <[hidden email]> 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 <[hidden email]> 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:
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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Adam Nemet via llvm-dev

Well… Ubuntu 16.04 came with gcc 5, and deploying Visual Studio 2015 should be a done deal in Windows shops, which suggests moving to C++14 should be no problem.

 

It's nice to see this week's version of MSVC supports C++17 but deploying through corporate IT can take a while.  ("This week's version" because the blog post is dated Monday.)

--paulr

 

From: llvm-dev [mailto:[hidden email]] On Behalf Of Zachary Turner via llvm-dev
Sent: Thursday, May 10, 2018 3:00 PM
To: JF Bastien
Cc: via llvm-dev
Subject: Re: [llvm-dev] Using C++14 code in LLVM

 

Consider me on board with the highest version we can come to an agreement on :)

 

 

On Thu, May 10, 2018 at 11:50 AM JF Bastien <[hidden email]> wrote:



On May 10, 2018, at 11:35 AM, Zachary Turner <[hidden email]> 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.

 

Such a fatalistic view, let’s trust ourselves to be better next time ;-)

But seriously: we can learn from moving to C++14, and use what we’ve learned to move to C++17 faster next time. Also consider the code churn we’ll encounter as we fix incompatibilities with C++11 / C++14, drop unnecessary code, upgrade various uses, that will happen regardless of moving to C++17 and will take a little while to occur. There would be more of that type of churn if we went straight to C++17.

 



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)?

 

Mostly library so far, yes, but the GCC 6 support for C++17 language isn’t great either:

 

 - New auto rules for direct-list-initialization

 - static_assert with no message

 - typename in a template template parameter

 - Nested namespace definition

 - Attributes for namespaces and enumerators

 - u8 character literals

 - Allow constant evaluation for all non-type template arguments

 - Fold Expressions

 - Unary fold expressions and empty parameter packs

 - __has_include in preprocessor conditional

 - Differing begin and end types in range-based for\

 

 

The only thing that’s really nice are fold expressions, and I hope they’re not buggy in GCC 6.

 

Otherwise the list is missing a good amount for C++17 language features, and brings up the discussion of which GCC version is the minimum we mandate. I’d rather avoid that discussion. Let’s assume GCC 6, if we get 7 then great, but it doesn’t matter if we stick to C++14.

 



On Thu, May 10, 2018 at 11:28 AM JF Bastien <[hidden email]> wrote:



On May 10, 2018, at 11:22 AM, Zachary Turner <[hidden email]> 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.

 



 

On Thu, May 10, 2018 at 11:18 AM Eric Christopher <[hidden email]> 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 <[hidden email]> 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:

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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Adam Nemet via llvm-dev
In reply to this post by Adam Nemet via llvm-dev

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

 

Thanks,

Evgeny

 

 

 

From: llvm-dev <[hidden email]> on behalf of Reid Kleckner via llvm-dev <[hidden email]>
Reply-To: Reid Kleckner <[hidden email]>
Date: Thursday, 10 May 2018 at 19:50
To: Zachary Turner <[hidden email]>
Cc: llvm-dev <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> wrote:



On May 10, 2018, at 11:22 AM, Zachary Turner <[hidden email]> 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.

 



 

On Thu, May 10, 2018 at 11:18 AM Eric Christopher <[hidden email]> 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 <[hidden email]> 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 (from C++14) right now †

·         Chromium started moving to C++14 in August of last year

·         Firefox uses some C++14

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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Adam Nemet via llvm-dev
In reply to this post by Adam Nemet via llvm-dev
Firefox's experience is that GCC 5 isn't going to cut it, especially
if you move to MSVC 2017, because people are going to be quickly
annoyed at the lack of relaxed constexpr function support, which is
GCC 6+.

You can get GCC 6 for Ubuntu 16.04; I have it on my machine, though
it's strangely not listed on packages.ubuntu.com for 16.04.

-Nathan

On Thu, May 10, 2018 at 3:20 PM, via llvm-dev <[hidden email]> wrote:

> Well… Ubuntu 16.04 came with gcc 5, and deploying Visual Studio 2015 should
> be a done deal in Windows shops, which suggests moving to C++14 should be no
> problem.
>
>
>
> It's nice to see this week's version of MSVC supports C++17 but deploying
> through corporate IT can take a while.  ("This week's version" because the
> blog post is dated Monday.)
>
> --paulr
>
>
>
> From: llvm-dev [mailto:[hidden email]] On Behalf Of Zachary
> Turner via llvm-dev
> Sent: Thursday, May 10, 2018 3:00 PM
> To: JF Bastien
> Cc: via llvm-dev
> Subject: Re: [llvm-dev] Using C++14 code in LLVM
>
>
>
> Consider me on board with the highest version we can come to an agreement on
> :)
>
>
>
>
>
> On Thu, May 10, 2018 at 11:50 AM JF Bastien <[hidden email]> wrote:
>
>
>
> On May 10, 2018, at 11:35 AM, Zachary Turner <[hidden email]> 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.
>
>
>
> Such a fatalistic view, let’s trust ourselves to be better next time ;-)
>
> But seriously: we can learn from moving to C++14, and use what we’ve learned
> to move to C++17 faster next time. Also consider the code churn we’ll
> encounter as we fix incompatibilities with C++11 / C++14, drop unnecessary
> code, upgrade various uses, that will happen regardless of moving to C++17
> and will take a little while to occur. There would be more of that type of
> churn if we went straight to C++17.
>
>
>
>
>
> 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)?
>
>
>
> Mostly library so far, yes, but the GCC 6 support for C++17 language isn’t
> great either:
>
>
>
>  - New auto rules for direct-list-initialization
>
>  - static_assert with no message
>
>  - typename in a template template parameter
>
>  - Nested namespace definition
>
>  - Attributes for namespaces and enumerators
>
>  - u8 character literals
>
>  - Allow constant evaluation for all non-type template arguments
>
>  - Fold Expressions
>
>  - Unary fold expressions and empty parameter packs
>
>  - __has_include in preprocessor conditional
>
>  - Differing begin and end types in range-based for\
>
>
>
> From: https://en.cppreference.com/w/cpp/compiler_support
>
>
>
> The only thing that’s really nice are fold expressions, and I hope they’re
> not buggy in GCC 6.
>
>
>
> Otherwise the list is missing a good amount for C++17 language features, and
> brings up the discussion of which GCC version is the minimum we mandate. I’d
> rather avoid that discussion. Let’s assume GCC 6, if we get 7 then great,
> but it doesn’t matter if we stick to C++14.
>
>
>
>
>
> On Thu, May 10, 2018 at 11:28 AM JF Bastien <[hidden email]> wrote:
>
>
>
> On May 10, 2018, at 11:22 AM, Zachary Turner <[hidden email]> 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 <[hidden email]>
> 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
> <[hidden email]> 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 (from C++14) right now †
> Chromium started moving to C++14 in August of last year
> Firefox uses some C++14
>
> 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
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Adam Nemet via llvm-dev
+1 to C++14.

On Thu, May 10, 2018 at 10:37 PM, Nathan Froyd via llvm-dev
<[hidden email]> wrote:
> Firefox's experience is that GCC 5 isn't going to cut it, especially
> if you move to MSVC 2017, because people are going to be quickly
> annoyed at the lack of relaxed constexpr function support, which is
> GCC 6+.
Are you sure? I think you meant GCC 4.9 isn't going to cut it, ...
...
annoyed at the lack of relaxed constexpr function support, which is
GCC 5.

https://gcc.gnu.org/projects/cxx-status.html.

Relaxing requirements on constexpr functionsN36525__cpp_constexpr >= 201304

Roman.

> You can get GCC 6 for Ubuntu 16.04; I have it on my machine, though
> it's strangely not listed on packages.ubuntu.com for 16.04.
>
> -Nathan
>
> On Thu, May 10, 2018 at 3:20 PM, via llvm-dev <[hidden email]> wrote:
>> Well… Ubuntu 16.04 came with gcc 5, and deploying Visual Studio 2015 should
>> be a done deal in Windows shops, which suggests moving to C++14 should be no
>> problem.
>>
>>
>>
>> It's nice to see this week's version of MSVC supports C++17 but deploying
>> through corporate IT can take a while.  ("This week's version" because the
>> blog post is dated Monday.)
>>
>> --paulr
>>
>>
>>
>> From: llvm-dev [mailto:[hidden email]] On Behalf Of Zachary
>> Turner via llvm-dev
>> Sent: Thursday, May 10, 2018 3:00 PM
>> To: JF Bastien
>> Cc: via llvm-dev
>> Subject: Re: [llvm-dev] Using C++14 code in LLVM
>>
>>
>>
>> Consider me on board with the highest version we can come to an agreement on
>> :)
>>
>>
>>
>>
>>
>> On Thu, May 10, 2018 at 11:50 AM JF Bastien <[hidden email]> wrote:
>>
>>
>>
>> On May 10, 2018, at 11:35 AM, Zachary Turner <[hidden email]> 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.
>>
>>
>>
>> Such a fatalistic view, let’s trust ourselves to be better next time ;-)
>>
>> But seriously: we can learn from moving to C++14, and use what we’ve learned
>> to move to C++17 faster next time. Also consider the code churn we’ll
>> encounter as we fix incompatibilities with C++11 / C++14, drop unnecessary
>> code, upgrade various uses, that will happen regardless of moving to C++17
>> and will take a little while to occur. There would be more of that type of
>> churn if we went straight to C++17.
>>
>>
>>
>>
>>
>> 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)?
>>
>>
>>
>> Mostly library so far, yes, but the GCC 6 support for C++17 language isn’t
>> great either:
>>
>>
>>
>>  - New auto rules for direct-list-initialization
>>
>>  - static_assert with no message
>>
>>  - typename in a template template parameter
>>
>>  - Nested namespace definition
>>
>>  - Attributes for namespaces and enumerators
>>
>>  - u8 character literals
>>
>>  - Allow constant evaluation for all non-type template arguments
>>
>>  - Fold Expressions
>>
>>  - Unary fold expressions and empty parameter packs
>>
>>  - __has_include in preprocessor conditional
>>
>>  - Differing begin and end types in range-based for\
>>
>>
>>
>> From: https://en.cppreference.com/w/cpp/compiler_support
>>
>>
>>
>> The only thing that’s really nice are fold expressions, and I hope they’re
>> not buggy in GCC 6.
>>
>>
>>
>> Otherwise the list is missing a good amount for C++17 language features, and
>> brings up the discussion of which GCC version is the minimum we mandate. I’d
>> rather avoid that discussion. Let’s assume GCC 6, if we get 7 then great,
>> but it doesn’t matter if we stick to C++14.
>>
>>
>>
>>
>>
>> On Thu, May 10, 2018 at 11:28 AM JF Bastien <[hidden email]> wrote:
>>
>>
>>
>> On May 10, 2018, at 11:22 AM, Zachary Turner <[hidden email]> 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 <[hidden email]>
>> 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
>> <[hidden email]> 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 (from C++14) right now †
>> Chromium started moving to C++14 in August of last year
>> Firefox uses some C++14
>>
>> 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
>> [hidden email]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> [hidden email]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Adam Nemet via llvm-dev
On Thu, May 10, 2018 at 3:40 PM, Roman Lebedev <[hidden email]> wrote:

> On Thu, May 10, 2018 at 10:37 PM, Nathan Froyd via llvm-dev
> <[hidden email]> wrote:
>> Firefox's experience is that GCC 5 isn't going to cut it, especially
>> if you move to MSVC 2017, because people are going to be quickly
>> annoyed at the lack of relaxed constexpr function support, which is
>> GCC 6+.
> Are you sure? I think you meant GCC 4.9 isn't going to cut it, ...
> ...
> annoyed at the lack of relaxed constexpr function support, which is
> GCC 5.

My fault!  You are correct; I got mixed up.  I cannot speak much to
GCC 5, since we went from GCC 4.9 to GCC 6.

MSVC 2015 and its (lack of) relaxed constexpr function support was a
pain point.  Some of that pain was because of external dependencies,
though, which is less of an issue for LLVM.

-Nathan
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Adam Nemet via llvm-dev
In reply to this post by Adam Nemet via llvm-dev


On May 10, 2018, at 12:25 PM, Evgeny Astigeevich via llvm-dev <[hidden email]> 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:

Thanks,
Evgeny
 
 
 
From: llvm-dev <[hidden email]> on behalf of Reid Kleckner via llvm-dev <[hidden email]>
Reply-To: Reid Kleckner <[hidden email]>
Date: Thursday, 10 May 2018 at 19:50
To: Zachary Turner <[hidden email]>
Cc: llvm-dev <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> wrote:


On May 10, 2018, at 11:22 AM, Zachary Turner <[hidden email]> 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.
 


 
On Thu, May 10, 2018 at 11:18 AM Eric Christopher <[hidden email]> 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 <[hidden email]> 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 (from C++14) right now †
·         Chromium started moving to C++14 in August of last year
·         Firefox uses some C++14
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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Adam Nemet via llvm-dev
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 <[hidden email]> wrote:

On May 10, 2018, at 12:25 PM, Evgeny Astigeevich via llvm-dev <[hidden email]> 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:

Thanks,
Evgeny
 
 
 
From: llvm-dev <[hidden email]> on behalf of Reid Kleckner via llvm-dev <[hidden email]>
Reply-To: Reid Kleckner <[hidden email]>
Date: Thursday, 10 May 2018 at 19:50
To: Zachary Turner <[hidden email]>
Cc: llvm-dev <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> wrote:


On May 10, 2018, at 11:22 AM, Zachary Turner <[hidden email]> 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.
 


 
On Thu, May 10, 2018 at 11:18 AM Eric Christopher <[hidden email]> 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 <[hidden email]> 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 (from C++14) right now †
·         Chromium started moving to C++14 in August of last year
·         Firefox uses some C++14
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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Adam Nemet via llvm-dev

On May 10, 2018, at 1:50 PM, Chandler Carruth <[hidden email]> 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. =[

Those people don’t build a browser? Because if they build any one of the 3 major ones they’re not using GCC 4.9 AFAICT.


On Thu, May 10, 2018 at 2:26 PM JF Bastien via llvm-dev <[hidden email]> wrote:

On May 10, 2018, at 12:25 PM, Evgeny Astigeevich via llvm-dev <[hidden email]> 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:

Thanks,
Evgeny
 
 
 
From: llvm-dev <[hidden email]> on behalf of Reid Kleckner via llvm-dev <[hidden email]>
Reply-To: Reid Kleckner <[hidden email]>
Date: Thursday, 10 May 2018 at 19:50
To: Zachary Turner <[hidden email]>
Cc: llvm-dev <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> wrote:


On May 10, 2018, at 11:22 AM, Zachary Turner <[hidden email]> 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.
 


 
On Thu, May 10, 2018 at 11:18 AM Eric Christopher <[hidden email]> 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 <[hidden email]> 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 (from C++14) right now †
·         Chromium started moving to C++14 in August of last year
·         Firefox uses some C++14
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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Adam Nemet via llvm-dev
In reply to this post by Adam Nemet via llvm-dev
On Thu, May 10, 2018 at 1:50 PM Chandler Carruth via llvm-dev <[hidden email]> 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. =[

"a decent amount of time" is very vague though, and is a good way of stalling forward progress.  How *much* time?  And when can we start the clock?

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Adam Nemet via llvm-dev
On Thu, May 10, 2018 at 3:10 PM Zachary Turner <[hidden email]> wrote:
On Thu, May 10, 2018 at 1:50 PM Chandler Carruth via llvm-dev <[hidden email]> 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. =[

"a decent amount of time" is very vague though, and is a good way of stalling forward progress.

Let's try to avoid implying bad intent. =/
 
  How *much* time?  And when can we start the clock?

I don't know. I can only speak to the use cases I'm aware of and care about. Whoever wants to drive this change needs to get a lot more feedback than just from me (IMO) about different users and whether a particular schedule will work.

And I already mentioned my schedule, but maybe not explicitly enough: the primary platform I care about is planning to be off of libstdc++4.9 (the tall poll of the tent for us) by the end of 2018. So it seems like right after the branch in January 2019 would be fine for us to bump things up. Anything earlier than this will be somewhere between extremely hard to infeasible for us.

At that point, we could probably go for C++17 as easily as C++14.

But maybe my group is unique in that timing so we should really ask others for input as well.

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Adam Nemet via llvm-dev
In reply to this post by Adam Nemet via llvm-dev
On Thu, May 10, 2018 at 3:06 PM JF Bastien <[hidden email]> wrote:
On May 10, 2018, at 1:50 PM, Chandler Carruth <[hidden email]> 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. =[

Those people don’t build a browser? Because if they build any one of the 3 major ones they’re not using GCC 4.9 AFAICT.

Probably not anywhere near the "trunk" of any of these browsers.

But while I know that browsers are pretty big, they are *not* primarily libraries. So their users very often don't need to compile them.

LLVM on the other hand is a library primarily, and so users of LLVM actually rely on being able to compile LLVM.

LLVM also has users on embedded platforms and other environments where browsers may not be prominent.

Anyways, my point is just that the browsers moving to C++14 is a good sign, but I don't think it is sufficient to say that we can just flip the switch.

-Chandler
 


On Thu, May 10, 2018 at 2:26 PM JF Bastien via llvm-dev <[hidden email]> wrote:

On May 10, 2018, at 12:25 PM, Evgeny Astigeevich via llvm-dev <[hidden email]> 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:

Thanks,
Evgeny
 
 
 
From: llvm-dev <[hidden email]> on behalf of Reid Kleckner via llvm-dev <[hidden email]>
Reply-To: Reid Kleckner <[hidden email]>
Date: Thursday, 10 May 2018 at 19:50
To: Zachary Turner <[hidden email]>
Cc: llvm-dev <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> wrote:


On May 10, 2018, at 11:22 AM, Zachary Turner <[hidden email]> 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.
 


 
On Thu, May 10, 2018 at 11:18 AM Eric Christopher <[hidden email]> 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 <[hidden email]> 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 (from C++14) right now †
·         Chromium started moving to C++14 in August of last year
·         Firefox uses some C++14
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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
12