llvm dev - May 2018 - Using C++14 code in LLVM

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 <llvm-dev at lists.llvm.org>
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:llvm-dev-bounces at lists.llvm.org] 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 <jfbastien at apple.com>
wrote:
>
>
>
> On May 10, 2018, at 11:35 AM, Zachary Turner <zturner at google.com>
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 <jfbastien at apple.com>
wrote:
>
>
>
> On May 10, 2018, at 11:22 AM, Zachary Turner <zturner at google.com>
wrote:
>
>
>
> Windows has never been the issue.  Honestly, MSVC on Windows is "fully
C++17
> conformant" [1].
>
>
>
> The issue has and always will be GCC.  Given that a bump in any version of
> GCC has been (and will remain) difficult for some time, I propose that we
> skip C++14 and move to 17.  We don't want to have a multi-year
disccusion
> about this again any time soon, and from what I gather, nobody has any more
> reservations about moving to C++17 than they do about moving to C++14. 
They
> only have reservations about moving to anything at all.  So if we're
gonna
> move, we should go all the way.
>
>
>
> WebKit’s move to C++17 hasn’t been super smooth because of GCC / libstdc++
> issues in both GCC 6 and GCC 7. It’s all fixable, but given LLVM's slow
move
> out of C++11 I’d rather get C++14 now rather than a painful transition to
> C++17 that drags on as we discover issues.
>
>
>
>
>
> Just my 2c.
>
>
>
> [1]
>
https://blogs.msdn.microsoft.com/vcblog/2018/05/07/announcing-msvc-conforms-to-the-c-standard/
>
>
>
> On Thu, May 10, 2018 at 11:18 AM Eric Christopher <echristo at
gmail.com>
> wrote:
>
> Once again, I'm totally down for this and think we should do it. I
worry
> about windows, but ...
>
>
>
> Zach: How's windows c++14 support looking?
>
>
>
> -eric
>
>
>
> On Thu, May 10, 2018 at 10:01 AM JF Bastien via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>
> Hi folks!
>
>
>
> Six more months have come and gone, and maybe we could move LLVM to C++14
> now?
>
>
>
> The issues I picked out from the last discussion:
>
> 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
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

+1 to C++14.

On Thu, May 10, 2018 at 10:37 PM, Nathan Froyd via llvm-dev
<llvm-dev at lists.llvm.org> 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 <llvm-dev at
lists.llvm.org> 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:llvm-dev-bounces at lists.llvm.org] 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 <jfbastien at
apple.com> wrote:
>>
>>
>>
>> On May 10, 2018, at 11:35 AM, Zachary Turner <zturner at
google.com> 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 <jfbastien at
apple.com> wrote:
>>
>>
>>
>> On May 10, 2018, at 11:22 AM, Zachary Turner <zturner at
google.com> wrote:
>>
>>
>>
>> Windows has never been the issue.  Honestly, MSVC on Windows is
"fully C++17
>> conformant" [1].
>>
>>
>>
>> The issue has and always will be GCC.  Given that a bump in any version
of
>> GCC has been (and will remain) difficult for some time, I propose that
we
>> skip C++14 and move to 17.  We don't want to have a multi-year
disccusion
>> about this again any time soon, and from what I gather, nobody has any
more
>> reservations about moving to C++17 than they do about moving to C++14. 
They
>> only have reservations about moving to anything at all.  So if
we're gonna
>> move, we should go all the way.
>>
>>
>>
>> WebKit’s move to C++17 hasn’t been super smooth because of GCC /
libstdc++
>> issues in both GCC 6 and GCC 7. It’s all fixable, but given LLVM's
slow move
>> out of C++11 I’d rather get C++14 now rather than a painful transition
to
>> C++17 that drags on as we discover issues.
>>
>>
>>
>>
>>
>> Just my 2c.
>>
>>
>>
>> [1]
>>
https://blogs.msdn.microsoft.com/vcblog/2018/05/07/announcing-msvc-conforms-to-the-c-standard/
>>
>>
>>
>> On Thu, May 10, 2018 at 11:18 AM Eric Christopher <echristo at
gmail.com>
>> wrote:
>>
>> Once again, I'm totally down for this and think we should do it. I
worry
>> about windows, but ...
>>
>>
>>
>> Zach: How's windows c++14 support looking?
>>
>>
>>
>> -eric
>>
>>
>>
>> On Thu, May 10, 2018 at 10:01 AM JF Bastien via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>>
>> Hi folks!
>>
>>
>>
>> Six more months have come and gone, and maybe we could move LLVM to
C++14
>> now?
>>
>>
>>
>> The issues I picked out from the last discussion:
>>
>> 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
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

On Thu, May 10, 2018 at 3:40 PM, Roman Lebedev <lebedev.ri at gmail.com>
wrote:
> On Thu, May 10, 2018 at 10:37 PM, Nathan Froyd via llvm-dev
> <llvm-dev at lists.llvm.org> 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