thr3ads.net - llvm dev - [llvm-dev] Using C++14 code in LLVM [May 2018]

If this information is useful, please help other people find it:
Share via:

Chandler Carruth via llvm-dev

2018-May-10 20:50 UTC

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

Last time this came up, there were a lot of people that were stuck on GCC
4.9 due to ABI reasons. I think forcing that upgrade is going to be the
most disruptive part of this, and I think that will really need a decent
amount of time. =[

On Thu, May 10, 2018 at 2:26 PM JF Bastien via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
> On May 10, 2018, at 12:25 PM, Evgeny Astigeevich via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hi,
>
> IMHO, it’s a good idea to move to C++14 first.
>
> What do you think about doing this by two phases:
>
> Phase1: require GCC >= 5 but build in C++11 mode (this will give time to
> adapt build infrastructure to a new gcc)
> Phase2: switch to C++14
>
>
> Sounds reasonable, here’s a patch:
> https://reviews.llvm.org/D46723
>
>
> Thanks,
> Evgeny
>
>
>
> *From: *llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of
Reid
> Kleckner via llvm-dev <llvm-dev at lists.llvm.org>
> *Reply-To: *Reid Kleckner <rnk at google.com>
> *Date: *Thursday, 10 May 2018 at 19:50
> *To: *Zachary Turner <zturner at google.com>
> *Cc: *llvm-dev <llvm-dev at lists.llvm.org>
> *Subject: *Re: [llvm-dev] Using C++14 code in LLVM
>
> The easy way not to have a three year discussion is to not worry about it
> for another three years. :)
>
> So, I think we should take the easy things on the table and just move to
> C++14 in the near future. It's just a matter of dropping support for
> building on distros that only have GCC <5 (aka Trusty, which is from
2014
> itself). Let's do that and call it a day.
>
> ---
> Aside: I'm always kind of amused by talk of moving to the next
"standard
> version" when the reality is that every C++ project is always held
back by
> the compilers and standard libraries that they actually use in practice. We
> say LLVM requires C++11 which mandates a working set of threading
> primitives, but in practice those don't exist on some platforms that
people
> would like us to support, so we end up maintaining the
> LLVM_ENABLE_THREADING=0 build for them.
>
> It seems more practical to simply list the minimum versions of supported
> toolchains that are commonly used to build, i.e. GCC 5, MSVC 2015, Clang
> 3.N, libc++ 3.N, libstdc++ 3.N, etc.
>
> On Thu, May 10, 2018 at 11:36 AM Zachary Turner via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> If it's the only thing we can agree then I'll take it, but I just
worry
> that 3 years from now we're going to start another 3 year discussion,
so
> that any actual move to C++17 would end up taking double the time.
>
> Are the issues specific to C++17 additions to the standard library?  What
> if you allow C++17 language features but not C++17 library features? 
I'm
> guessing this is too simple though and isn't sufficient to avoid the
> problems (which I don't know anything about, so you'll have to
enlighten
> me)?
>
> On Thu, May 10, 2018 at 11:28 AM JF Bastien <jfbastien at apple.com>
wrote:
>
>
>
> On May 10, 2018, at 11:22 AM, Zachary Turner <zturner at google.com>
wrote:
>
> Windows has never been the issue.  Honestly, MSVC on Windows is "fully
> C++17 conformant" [1].
>
> The issue has and always will be GCC.  Given that a bump in any version of
> GCC has been (and will remain) difficult for some time, I propose that we
> skip C++14 and move to 17.  We don't want to have a multi-year
disccusion
> about this again any time soon, and from what I gather, nobody has any more
> reservations about moving to C++17 than they do about moving to C++14.
> They only have reservations about moving to anything at all.  So if
we're
> gonna move, we should go all the way.
>
>
> WebKit’s move to C++17 hasn’t been super smooth because of GCC / libstdc++
> issues in both GCC 6 and GCC 7. It’s all fixable, but given LLVM's slow
> move out of C++11 I’d rather get C++14 now rather than a painful transition
> to C++17 that drags on as we discover issues.
>
>
>
> Just my 2c.
>
> [1]
>
https://blogs.msdn.microsoft.com/vcblog/2018/05/07/announcing-msvc-conforms-to-the-c-standard/
>
> On Thu, May 10, 2018 at 11:18 AM Eric Christopher <echristo at
gmail.com>
> wrote:
>
> Once again, I'm totally down for this and think we should do it. I
worry
> about windows, but ...
>
> Zach: How's windows c++14 support looking?
>
> -eric
>
> On Thu, May 10, 2018 at 10:01 AM JF Bastien via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hi folks!
>
> Six more months have come and gone, and maybe we could move LLVM to C++14
> now?
>
> The issues I picked out from the last discussion:
> 1.       Some folks want an official policy about compiler support before
> updating the standard version we use.
> 2.       Worries about which GCC version is available in which distro.
> 3.       Worries about MSVC.
>
> Instead of rehashing the compiler per distro surveys from previous
> discussion, and instead of talking bootstrap, let me offer three data
> points:
> ·         WebKit is moving to C++17
>
<https://lists.webkit.org/pipermail/webkit-dev/2018-March/029922.html>
(from
> C++14) right now †
> ·         Chromium started moving to C++14
>
<https://groups.google.com/a/chromium.org/d/msg/cxx/ow7hmdDm4yw/eV6KWL2yAQAJ>
in
> August of last year
> ·         Firefox uses some C++14
>
<https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code>
> What I get from this data: if your distro bundles a modern web browser, it
> already builds some C++14, *somehow*.
>
> The LLVM community has been talking about this for a while now, and I’m
> not aware of a policy coming to light. I don’t think we need a policy given
> the above data. So how about we… just kinda... move LLVM to C++14?
>
>
> Thanks!
>
> JF
>
>
> † the move to C++17 is very painful, but 14 has been working great in
> WebKit for quite a long time.
>
>
> > Last time we discussed this, the consensus was "I think we can
survive
> > another year without generalized constexpr and variable
templates".
> >
> > Well, we did indeed survive.   And it's been exactly a year!  So
> naturally,
> > it only makes sense to revive this :)
> >
> >
> >
> > There's an active conversation going on in IRC right now, and it
seems
> like
> > there is more desire than there was last year.
> >
> > What are the main gains from allowing C++14?
> > * Variable templates
> > * Generalized constexpr
> > * Return-type Deduction
> > * Generic Lambdas
> > * std::make_unique<> (the source of many build bot breakages)
> >
> >
> > What are the main gains from allowing C++17?  [1]
> > * [[nodiscard]] attribute
> > * structured bindings
> > * constexpr-if
> > * guaranteed copy elision
> > * numerous new library types: optional, string_view, variant, byte,
> > * numerous new algorithms: parallel algorithms, too many to list
> > * Probably some more, but I just tried to hit the biggest ones.
> >
> >
> > First, it seems like if we want to enable C++14 we need GCC >= 5.
> > And if we want to enable C++17 we need GCC >= 7.
> >
> > With that out of the way, here were some of the issues that were
raised
> > last time:
> >
> > Issue: Ubuntu 14.04 LTS is on GCC 4.8.x, and we have to support it
until
> > end of life.
> > Resolution: LTS is right around the corner, in 6 more months.
> >
> > Issue: Various other platforms have older GCCs as their system
compiler,
> > and it's annoying to upgrade.
> > Question: Do any of these not have a port you can install?  For
example,
> > NetBSD 7 appears to have GCC 5.3 as a port, if DistroWatch is any
> > indication.  It could be wrong though and I could also be
misinterpreting
> > it.
> >
> > Issue: If we're going to make people bootstrap a compiler, we
might as
> well
> > go all the way to C++17.
> > Comment: I'm not opposed.
> >
> >
> > Some questions / comments of my own:
> >
> > * Where is this policy about Ubuntu and LTS documented?  Does this
mean,
> > for example, that we will not be able to use C++17 until 2023 (16.04
LTS
> > has only GCC 5.3.1)?  That seems a bit unreasonable.  And there's
no
> > guarantee that 18.04 LTS will even have GCC 7 or higher either, so it
> could
> > be 2025 or 2027.
> >
> > * We've asked people in the past to build a modern toolchain.  For
> example,
> > we did it with C++11 and Ubuntu 12.04 LTS.  Is C++17 compelling enough
to
> > justify this again?
> >
> > * GCC 4.9 probably isn't sufficient to justify an increase for
anyone, as
> > it lacks two of the more sought-after features of C++14 (variable
> templates
> > and generalized constexpr).  So IMO we should require a bump to GCC 5
or
> > higher, or not at all.
> >
> > * Clang 6 supports all of C++20, and it builds with only C++11, so we
> > shouldn't have to worry too much about the problem of needing to
"daisy
> > chain" compilers to finally get the latest version of LLVM
building.
>  "GCC
> > 4.8 -> Clang 6 - > Clang ToT" should hold up through C++1z.
> >
> > * While we obviously can't be tied to the versioning of every
single
> distro
> > out there, some are "bigger" than others.  Which are big
enough that
> > warrant serious consideration?  The ones I found are (and I did my
best
> to
> > aggregate all this, but please correct me if anything is incorrect or
> > misrepresented):
> >
> > OpenBSD - Ships with GCC 4.2.1 anyway.  They are already having to
> > bootstrap something, so the proposal here does not change anything,
> because
> > even current LLVM doesn't compile with GCC 4.2.1
> >
> > CentOS & RHEL - No version of Distro, including trunk, has GCC
>= 4.8.5
> > (are there ports?)
> >
> > Debian - Minimum version 9 for GCC >= 5  (are there ports for
earlier
> > releases?)
> >
> > Fedora - Minimum version 24 for GCC >= 5, minimum version 26 for
GCC >= 7
> >
> > Ubuntu - Minimum LTS 16.04 for GCC >= 5
> >
> > NetBSD - Version 7 has GCC 4.8.4 by default, but contains port for
5.3.0
> >
> > FreeBSD - Minimum Version 11 for GCC >= 5
> >
> > So, thoughts?
> >
> >
> > [1] - Note that we'd need to wait a few more revs for MSVC before
> allowing
> > C++17, but given that it's becoming easier and easier to bump the
minimum
> > MSVC version, I'm discounting this as a factor, as MSVC will not
really
> be
> > the bottleneck in any real sense.
> >
> > On Tue, Oct 4, 2016 at 2:15 PM Mehdi Amini <mehdi.amini at
apple.com>
> wrote:
> >
> >>
> >> On Oct 4, 2016, at 2:10 PM, Reid Kleckner <rnk at
google.com> wrote:
> >>
> >> On Tue, Oct 4, 2016 at 11:58 AM, Mehdi Amini <mehdi.amini at
apple.com>
> >> wrote:
> >>
> >>>
> >>> On Oct 4, 2016, at 8:40 AM, Reid Kleckner via llvm-dev <
> >>> llvm-dev at lists.llvm.org> wrote:
> >>>
> >>> On Tue, Oct 4, 2016 at 8:29 AM, Zachary Turner <zturner at
google.com>
> >>> wrote:
> >>>>
> >>>> I ask because many of these LTS distros are notoriously
slow at
> updating
> >>>> their packages. While some people may think C++14
doesn't provide
> enough
> >>>> bang for the buck to justify bumping to GCC 4.9, C++17
definitely
> does. But
> >>>> at that point we're going to be talking about GCC 6.1
or 6.2, which is
> >>>> going to be significantly harder unless we want to wait
5-7 years,
> and I
> >>>> suspect people won't.
> >>>>
> >>>
> >>> If by "notoriously slow" you mean they don't
bump their toolchain
> >>> versions at all, then yeah. We just wait until the LTS release
is at
> >>> end-of-life before dropping it.
> >>>
> >>>
> >>> That’s the first time I read about this policy: we support
every linux
> >>> LTS distribution till their end-of-life? Only Ubuntu? Do you
have a
> pointer
> >>> where it is documented / discussed?
> >>> (Note that Ubuntu LTS is 5 years AFAIK.)
> >>>
> >>
> >> Sorry, I didn't mean to refer to the LTS support lifetime. I
just meant
> we
> >> support the last LTS until we can reasonably expect users to have
> upgraded
> >> to the new one. If there's an LTS release every two years,
then we want
> to
> >> keep supporting them for at least three years to give people a
year to
> >> upgrade.
> >>
> >>
> >> OK, got it.
> >>
> >> Thanks for clarifying!
> >>
> >> Mehdi
> >>
> >>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> 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
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180510/56c838c6/attachment.html>

JF Bastien via llvm-dev

2018-May-10 21:06 UTC

head link

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

> On May 10, 2018, at 1:50 PM, Chandler Carruth <chandlerc at
google.com> 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 <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> 
>> On May 10, 2018, at 12:25 PM, Evgeny Astigeevich via llvm-dev
<llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
wrote:
>> 
>> Hi,
>>  
>> IMHO, it’s a good idea to move to C++14 first.
>>  
>> What do you think about doing this by two phases:
>>  
>> Phase1: require GCC >= 5 but build in C++11 mode (this will give
time to adapt build infrastructure to a new gcc)
>> Phase2: switch to C++14
> 
> Sounds reasonable, here’s a patch:
> https://reviews.llvm.org/D46723 <https://reviews.llvm.org/D46723>
> 
> 
>> Thanks,
>> Evgeny
>>  
>>  
>>  
>> From: llvm-dev <llvm-dev-bounces at lists.llvm.org
<mailto:llvm-dev-bounces at lists.llvm.org>> on behalf of Reid Kleckner
via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>>
>> Reply-To: Reid Kleckner <rnk at google.com <mailto:rnk at
google.com>>
>> Date: Thursday, 10 May 2018 at 19:50
>> To: Zachary Turner <zturner at google.com <mailto:zturner at
google.com>>
>> Cc: llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>>
>> Subject: Re: [llvm-dev] Using C++14 code in LLVM
>>  
>> The easy way not to have a three year discussion is to not worry about
it for another three years. :)
>>  
>> So, I think we should take the easy things on the table and just move
to C++14 in the near future. It's just a matter of dropping support for
building on distros that only have GCC <5 (aka Trusty, which is from 2014
itself). Let's do that and call it a day.
>>  
>> ---
>> Aside: I'm always kind of amused by talk of moving to the next
"standard version" when the reality is that every C++ project is
always held back by the compilers and standard libraries that they actually use
in practice. We say LLVM requires C++11 which mandates a working set of
threading primitives, but in practice those don't exist on some platforms
that people would like us to support, so we end up maintaining the
LLVM_ENABLE_THREADING=0 build for them.
>>  
>> It seems more practical to simply list the minimum versions of
supported toolchains that are commonly used to build, i.e. GCC 5, MSVC 2015,
Clang 3.N, libc++ 3.N, libstdc++ 3.N, etc.
>>  
>> On Thu, May 10, 2018 at 11:36 AM Zachary Turner via llvm-dev
<llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
wrote:
>>> If it's the only thing we can agree then I'll take it, but
I just worry that 3 years from now we're going to start another 3 year
discussion, so that any actual move to C++17 would end up taking double the
time.
>>>  
>>> Are the issues specific to C++17 additions to the standard library?
What if you allow C++17 language features but not C++17 library features? 
I'm guessing this is too simple though and isn't sufficient to avoid the
problems (which I don't know anything about, so you'll have to enlighten
me)?
>>>  
>>> On Thu, May 10, 2018 at 11:28 AM JF Bastien <jfbastien at
apple.com <mailto:jfbastien at apple.com>> wrote:
>>>> 
>>>> 
>>>>> On May 10, 2018, at 11:22 AM, Zachary Turner <zturner at
google.com <mailto:zturner at google.com>> wrote:
>>>>>  
>>>>> Windows has never been the issue.  Honestly, MSVC on
Windows is "fully C++17 conformant" [1].
>>>>>  
>>>>> The issue has and always will be GCC.  Given that a bump in
any version of GCC has been (and will remain) difficult for some time, I propose
that we skip C++14 and move to 17.  We don't want to have a multi-year
disccusion about this again any time soon, and from what I gather, nobody has
any more reservations about moving to C++17 than they do about moving to C++14. 
They only have reservations about moving to anything at all.  So if we're
gonna move, we should go all the way.
>>>>  
>>>> WebKit’s move to C++17 hasn’t been super smooth because of GCC
/ libstdc++ issues in both GCC 6 and GCC 7. It’s all fixable, but given
LLVM's slow move out of C++11 I’d rather get C++14 now rather than a painful
transition to C++17 that drags on as we discover issues.
>>>>  
>>>> 
>>>> 
>>>>> Just my 2c.
>>>>>  
>>>>> [1]
https://blogs.msdn.microsoft.com/vcblog/2018/05/07/announcing-msvc-conforms-to-the-c-standard/
<https://blogs.msdn.microsoft.com/vcblog/2018/05/07/announcing-msvc-conforms-to-the-c-standard/>
>>>>>  
>>>>> On Thu, May 10, 2018 at 11:18 AM Eric Christopher
<echristo at gmail.com <mailto:echristo at gmail.com>> wrote:
>>>>>> Once again, I'm totally down for this and think we
should do it. I worry about windows, but ...
>>>>>>  
>>>>>> Zach: How's windows c++14 support looking?
>>>>>>  
>>>>>> -eric
>>>>>>  
>>>>>> On Thu, May 10, 2018 at 10:01 AM JF Bastien via
llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
>>>>>>> Hi folks!
>>>>>>>  
>>>>>>> Six more months have come and gone, and maybe we
could move LLVM to C++14 now?
>>>>>>>  
>>>>>>> The issues I picked out from the last discussion:
>>>>>>> 1.       Some folks want an official policy about
compiler support before updating the standard version we use.
>>>>>>> 2.       Worries about which GCC version is
available in which distro.
>>>>>>> 3.       Worries about MSVC.
>>>>>>>  
>>>>>>> Instead of rehashing the compiler per distro
surveys from previous discussion, and instead of talking bootstrap, let me offer
three data points:
>>>>>>> ·         WebKit is moving to C++17
<https://lists.webkit.org/pipermail/webkit-dev/2018-March/029922.html>
(from C++14) right now †
>>>>>>> ·         Chromium started moving to C++14
<https://groups.google.com/a/chromium.org/d/msg/cxx/ow7hmdDm4yw/eV6KWL2yAQAJ>
in August of last year
>>>>>>> ·         Firefox uses some C++14
<https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code>
>>>>>>> What I get from this data: if your distro bundles a
modern web browser, it already builds some C++14, somehow.
>>>>>>>  
>>>>>>> The LLVM community has been talking about this for
a while now, and I’m not aware of a policy coming to light. I don’t think we
need a policy given the above data. So how about we… just kinda... move LLVM to
C++14?
>>>>>>>  
>>>>>>>  
>>>>>>> Thanks!
>>>>>>>  
>>>>>>> JF
>>>>>>>  
>>>>>>>  
>>>>>>> † the move to C++17 is very painful, but 14 has
been working great in WebKit for quite a long time.
>>>>>>>  
>>>>>>>  
>>>>>>> > Last time we discussed this, the consensus was
"I think we can survive
>>>>>>> > another year without generalized constexpr and
variable templates".
>>>>>>> > 
>>>>>>> > Well, we did indeed survive.   And it's
been exactly a year!  So naturally,
>>>>>>> > it only makes sense to revive this :)
>>>>>>> > 
>>>>>>> > 
>>>>>>> > 
>>>>>>> > There's an active conversation going on in
IRC right now, and it seems like
>>>>>>> > there is more desire than there was last year.
>>>>>>> > 
>>>>>>> > What are the main gains from allowing C++14?
>>>>>>> > * Variable templates
>>>>>>> > * Generalized constexpr
>>>>>>> > * Return-type Deduction
>>>>>>> > * Generic Lambdas
>>>>>>> > * std::make_unique<> (the source of many
build bot breakages)
>>>>>>> > 
>>>>>>> > 
>>>>>>> > What are the main gains from allowing C++17? 
[1]
>>>>>>> > * [[nodiscard]] attribute
>>>>>>> > * structured bindings
>>>>>>> > * constexpr-if
>>>>>>> > * guaranteed copy elision
>>>>>>> > * numerous new library types: optional,
string_view, variant, byte,
>>>>>>> > * numerous new algorithms: parallel
algorithms, too many to list
>>>>>>> > * Probably some more, but I just tried to hit
the biggest ones.
>>>>>>> > 
>>>>>>> > 
>>>>>>> > First, it seems like if we want to enable
C++14 we need GCC >= 5.
>>>>>>> > And if we want to enable C++17 we need GCC
>= 7.
>>>>>>> > 
>>>>>>> > With that out of the way, here were some of
the issues that were raised
>>>>>>> > last time:
>>>>>>> > 
>>>>>>> > Issue: Ubuntu 14.04 LTS is on GCC 4.8.x, and
we have to support it until
>>>>>>> > end of life.
>>>>>>> > Resolution: LTS is right around the corner, in
6 more months.
>>>>>>> > 
>>>>>>> > Issue: Various other platforms have older GCCs
as their system compiler,
>>>>>>> > and it's annoying to upgrade.
>>>>>>> > Question: Do any of these not have a port you
can install?  For example,
>>>>>>> > NetBSD 7 appears to have GCC 5.3 as a port, if
DistroWatch is any
>>>>>>> > indication.  It could be wrong though and I
could also be misinterpreting
>>>>>>> > it.
>>>>>>> > 
>>>>>>> > Issue: If we're going to make people
bootstrap a compiler, we might as well
>>>>>>> > go all the way to C++17.
>>>>>>> > Comment: I'm not opposed.
>>>>>>> > 
>>>>>>> > 
>>>>>>> > Some questions / comments of my own:
>>>>>>> > 
>>>>>>> > * Where is this policy about Ubuntu and LTS
documented?  Does this mean,
>>>>>>> > for example, that we will not be able to use
C++17 until 2023 (16.04 LTS
>>>>>>> > has only GCC 5.3.1)?  That seems a bit
unreasonable.  And there's no
>>>>>>> > guarantee that 18.04 LTS will even have GCC 7
or higher either, so it could
>>>>>>> > be 2025 or 2027.
>>>>>>> > 
>>>>>>> > * We've asked people in the past to build
a modern toolchain.  For example,
>>>>>>> > we did it with C++11 and Ubuntu 12.04 LTS.  Is
C++17 compelling enough to
>>>>>>> > justify this again?
>>>>>>> > 
>>>>>>> > * GCC 4.9 probably isn't sufficient to
justify an increase for anyone, as
>>>>>>> > it lacks two of the more sought-after features
of C++14 (variable templates
>>>>>>> > and generalized constexpr).  So IMO we should
require a bump to GCC 5 or
>>>>>>> > higher, or not at all.
>>>>>>> > 
>>>>>>> > * Clang 6 supports all of C++20, and it builds
with only C++11, so we
>>>>>>> > shouldn't have to worry too much about the
problem of needing to "daisy
>>>>>>> > chain" compilers to finally get the
latest version of LLVM building.  "GCC
>>>>>>> > 4.8 -> Clang 6 - > Clang ToT"
should hold up through C++1z.
>>>>>>> > 
>>>>>>> > * While we obviously can't be tied to the
versioning of every single distro
>>>>>>> > out there, some are "bigger" than
others.  Which are big enough that
>>>>>>> > warrant serious consideration?  The ones I
found are (and I did my best to
>>>>>>> > aggregate all this, but please correct me if
anything is incorrect or
>>>>>>> > misrepresented):
>>>>>>> > 
>>>>>>> > OpenBSD - Ships with GCC 4.2.1 anyway.  They
are already having to
>>>>>>> > bootstrap something, so the proposal here does
not change anything, because
>>>>>>> > even current LLVM doesn't compile with GCC
4.2.1
>>>>>>> > 
>>>>>>> > CentOS & RHEL - No version of Distro,
including trunk, has GCC >= 4.8.5
>>>>>>> > (are there ports?)
>>>>>>> > 
>>>>>>> > Debian - Minimum version 9 for GCC >= 5 
(are there ports for earlier
>>>>>>> > releases?)
>>>>>>> > 
>>>>>>> > Fedora - Minimum version 24 for GCC >= 5,
minimum version 26 for GCC >= 7
>>>>>>> > 
>>>>>>> > Ubuntu - Minimum LTS 16.04 for GCC >= 5
>>>>>>> > 
>>>>>>> > NetBSD - Version 7 has GCC 4.8.4 by default,
but contains port for 5.3.0
>>>>>>> > 
>>>>>>> > FreeBSD - Minimum Version 11 for GCC >= 5
>>>>>>> > 
>>>>>>> > So, thoughts?
>>>>>>> > 
>>>>>>> > 
>>>>>>> > [1] - Note that we'd need to wait a few
more revs for MSVC before allowing
>>>>>>> > C++17, but given that it's becoming easier
and easier to bump the minimum
>>>>>>> > MSVC version, I'm discounting this as a
factor, as MSVC will not really be
>>>>>>> > the bottleneck in any real sense.
>>>>>>> > 
>>>>>>> > On Tue, Oct 4, 2016 at 2:15 PM Mehdi Amini
<mehdi.amini at apple.com <http://apple.com/>> wrote:
>>>>>>> > 
>>>>>>> >> 
>>>>>>> >> On Oct 4, 2016, at 2:10 PM, Reid Kleckner
<rnk at google.com <http://google.com/>> wrote:
>>>>>>> >> 
>>>>>>> >> On Tue, Oct 4, 2016 at 11:58 AM, Mehdi
Amini <mehdi.amini at apple.com <http://apple.com/>>
>>>>>>> >> wrote:
>>>>>>> >> 
>>>>>>> >>> 
>>>>>>> >>> On Oct 4, 2016, at 8:40 AM, Reid
Kleckner via llvm-dev <
>>>>>>> >>> llvm-dev at lists.llvm.org
<http://lists.llvm.org/>> wrote:
>>>>>>> >>> 
>>>>>>> >>> On Tue, Oct 4, 2016 at 8:29 AM,
Zachary Turner <zturner at google.com <http://google.com/>>
>>>>>>> >>> wrote:
>>>>>>> >>>> 
>>>>>>> >>>> I ask because many of these LTS
distros are notoriously slow at updating
>>>>>>> >>>> their packages. While some people
may think C++14 doesn't provide enough
>>>>>>> >>>> bang for the buck to justify
bumping to GCC 4.9, C++17 definitely does. But
>>>>>>> >>>> at that point we're going to
be talking about GCC 6.1 or 6.2, which is
>>>>>>> >>>> going to be significantly harder
unless we want to wait 5-7 years, and I
>>>>>>> >>>> suspect people won't.
>>>>>>> >>>> 
>>>>>>> >>> 
>>>>>>> >>> If by "notoriously slow" you
mean they don't bump their toolchain
>>>>>>> >>> versions at all, then yeah. We just
wait until the LTS release is at
>>>>>>> >>> end-of-life before dropping it.
>>>>>>> >>> 
>>>>>>> >>> 
>>>>>>> >>> That’s the first time I read about
this policy: we support every linux
>>>>>>> >>> LTS distribution till their
end-of-life? Only Ubuntu? Do you have a pointer
>>>>>>> >>> where it is documented / discussed?
>>>>>>> >>> (Note that Ubuntu LTS is 5 years
AFAIK.)
>>>>>>> >>> 
>>>>>>> >> 
>>>>>>> >> Sorry, I didn't mean to refer to the
LTS support lifetime. I just meant we
>>>>>>> >> support the last LTS until we can
reasonably expect users to have upgraded
>>>>>>> >> to the new one. If there's an LTS
release every two years, then we want to
>>>>>>> >> keep supporting them for at least three
years to give people a year to
>>>>>>> >> upgrade.
>>>>>>> >> 
>>>>>>> >> 
>>>>>>> >> OK, got it.
>>>>>>> >> 
>>>>>>> >> Thanks for clarifying!
>>>>>>> >> 
>>>>>>> >> Mehdi
>>>>>>> >> 
>>>>>>> >> 
>>>>>>> _______________________________________________
>>>>>>> LLVM Developers mailing list
>>>>>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>>>>>>>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>_______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180510/54d57752/attachment.html>

Zachary Turner via llvm-dev

2018-May-10 21:10 UTC

head link

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

On Thu, May 10, 2018 at 1:50 PM Chandler Carruth via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Last time this came up, there were a lot of people that were stuck on GCC
> 4.9 due to ABI reasons. I think forcing that upgrade is going to be the
> most disruptive part of this, and I think that will really need a decent
> amount of time. =[
>
"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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180510/efbe6010/attachment-0001.html>

Chandler Carruth via llvm-dev

2018-May-10 21:21 UTC

head link

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

On Thu, May 10, 2018 at 3:10 PM Zachary Turner <zturner at google.com>
wrote:
> On Thu, May 10, 2018 at 1:50 PM Chandler Carruth via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Last time this came up, there were a lot of people that were stuck on
GCC
>> 4.9 due to ABI reasons. I think forcing that upgrade is going to be the
>> most disruptive part of this, and I think that will really need a
decent
>> amount of time. =[
>>
>
> "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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180510/5fe44af0/attachment.html>

Chandler Carruth via llvm-dev

2018-May-10 21:27 UTC

head link

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

On Thu, May 10, 2018 at 3:06 PM JF Bastien <jfbastien at apple.com> wrote:
> On May 10, 2018, at 1:50 PM, Chandler Carruth <chandlerc at
google.com>
> 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 <
> llvm-dev at lists.llvm.org> wrote:
>
>>
>> On May 10, 2018, at 12:25 PM, Evgeny Astigeevich via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>> Hi,
>>
>> IMHO, it’s a good idea to move to C++14 first.
>>
>> What do you think about doing this by two phases:
>>
>> Phase1: require GCC >= 5 but build in C++11 mode (this will give
time to
>> adapt build infrastructure to a new gcc)
>> Phase2: switch to C++14
>>
>>
>> Sounds reasonable, here’s a patch:
>> https://reviews.llvm.org/D46723
>>
>>
>> Thanks,
>> Evgeny
>>
>>
>>
>> *From: *llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf
of Reid
>> Kleckner via llvm-dev <llvm-dev at lists.llvm.org>
>> *Reply-To: *Reid Kleckner <rnk at google.com>
>> *Date: *Thursday, 10 May 2018 at 19:50
>> *To: *Zachary Turner <zturner at google.com>
>> *Cc: *llvm-dev <llvm-dev at lists.llvm.org>
>> *Subject: *Re: [llvm-dev] Using C++14 code in LLVM
>>
>> The easy way not to have a three year discussion is to not worry about
it
>> for another three years. :)
>>
>> So, I think we should take the easy things on the table and just move
to
>> C++14 in the near future. It's just a matter of dropping support
for
>> building on distros that only have GCC <5 (aka Trusty, which is from
2014
>> itself). Let's do that and call it a day.
>>
>> ---
>> Aside: I'm always kind of amused by talk of moving to the next
"standard
>> version" when the reality is that every C++ project is always held
back by
>> the compilers and standard libraries that they actually use in
practice. We
>> say LLVM requires C++11 which mandates a working set of threading
>> primitives, but in practice those don't exist on some platforms
that people
>> would like us to support, so we end up maintaining the
>> LLVM_ENABLE_THREADING=0 build for them.
>>
>> It seems more practical to simply list the minimum versions of
supported
>> toolchains that are commonly used to build, i.e. GCC 5, MSVC 2015,
Clang
>> 3.N, libc++ 3.N, libstdc++ 3.N, etc.
>>
>> On Thu, May 10, 2018 at 11:36 AM Zachary Turner via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>> If it's the only thing we can agree then I'll take it, but I
just worry
>> that 3 years from now we're going to start another 3 year
discussion, so
>> that any actual move to C++17 would end up taking double the time.
>>
>> Are the issues specific to C++17 additions to the standard library? 
What
>> if you allow C++17 language features but not C++17 library features? 
I'm
>> guessing this is too simple though and isn't sufficient to avoid
the
>> problems (which I don't know anything about, so you'll have to
enlighten
>> me)?
>>
>> On Thu, May 10, 2018 at 11:28 AM JF Bastien <jfbastien at
apple.com> wrote:
>>
>>
>>
>> On May 10, 2018, at 11:22 AM, Zachary Turner <zturner at
google.com> wrote:
>>
>> Windows has never been the issue.  Honestly, MSVC on Windows is
"fully
>> C++17 conformant" [1].
>>
>> The issue has and always will be GCC.  Given that a bump in any version
>> of GCC has been (and will remain) difficult for some time, I propose
that
>> we skip C++14 and move to 17.  We don't want to have a multi-year
>> disccusion about this again any time soon, and from what I gather,
nobody
>> has any more reservations about moving to C++17 than they do about
moving
>> to C++14.  They only have reservations about moving to anything at all.
So
>> if we're gonna move, we should go all the way.
>>
>>
>> WebKit’s move to C++17 hasn’t been super smooth because of GCC /
>> libstdc++ issues in both GCC 6 and GCC 7. It’s all fixable, but given
>> LLVM's slow move out of C++11 I’d rather get C++14 now rather than
a
>> painful transition to C++17 that drags on as we discover issues.
>>
>>
>>
>> Just my 2c.
>>
>> [1]
>>
https://blogs.msdn.microsoft.com/vcblog/2018/05/07/announcing-msvc-conforms-to-the-c-standard/
>>
>> On Thu, May 10, 2018 at 11:18 AM Eric Christopher <echristo at
gmail.com>
>> wrote:
>>
>> Once again, I'm totally down for this and think we should do it. I
worry
>> about windows, but ...
>>
>> Zach: How's windows c++14 support looking?
>>
>> -eric
>>
>> On Thu, May 10, 2018 at 10:01 AM JF Bastien via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>> Hi folks!
>>
>> Six more months have come and gone, and maybe we could move LLVM to
C++14
>> now?
>>
>> The issues I picked out from the last discussion:
>> 1.       Some folks want an official policy about compiler support
>> before updating the standard version we use.
>> 2.       Worries about which GCC version is available in which distro.
>> 3.       Worries about MSVC.
>>
>> Instead of rehashing the compiler per distro surveys from previous
>> discussion, and instead of talking bootstrap, let me offer three data
>> points:
>> ·         WebKit is moving to C++17
>>
<https://lists.webkit.org/pipermail/webkit-dev/2018-March/029922.html>
(from
>> C++14) right now †
>> ·         Chromium started moving to C++14
>>
<https://groups.google.com/a/chromium.org/d/msg/cxx/ow7hmdDm4yw/eV6KWL2yAQAJ>
in
>> August of last year
>> ·         Firefox uses some C++14
>>
<https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code>
>> What I get from this data: if your distro bundles a modern web browser,
>> it already builds some C++14, *somehow*.
>>
>> The LLVM community has been talking about this for a while now, and I’m
>> not aware of a policy coming to light. I don’t think we need a policy
given
>> the above data. So how about we… just kinda... move LLVM to C++14?
>>
>>
>> Thanks!
>>
>> JF
>>
>>
>> † the move to C++17 is very painful, but 14 has been working great in
>> WebKit for quite a long time.
>>
>>
>> > Last time we discussed this, the consensus was "I think we
can survive
>> > another year without generalized constexpr and variable
templates".
>> >
>> > Well, we did indeed survive.   And it's been exactly a year! 
So
>> naturally,
>> > it only makes sense to revive this :)
>> >
>> >
>> >
>> > There's an active conversation going on in IRC right now, and
it seems
>> like
>> > there is more desire than there was last year.
>> >
>> > What are the main gains from allowing C++14?
>> > * Variable templates
>> > * Generalized constexpr
>> > * Return-type Deduction
>> > * Generic Lambdas
>> > * std::make_unique<> (the source of many build bot
breakages)
>> >
>> >
>> > What are the main gains from allowing C++17?  [1]
>> > * [[nodiscard]] attribute
>> > * structured bindings
>> > * constexpr-if
>> > * guaranteed copy elision
>> > * numerous new library types: optional, string_view, variant,
byte,
>> > * numerous new algorithms: parallel algorithms, too many to list
>> > * Probably some more, but I just tried to hit the biggest ones.
>> >
>> >
>> > First, it seems like if we want to enable C++14 we need GCC >=
5.
>> > And if we want to enable C++17 we need GCC >= 7.
>> >
>> > With that out of the way, here were some of the issues that were
raised
>> > last time:
>> >
>> > Issue: Ubuntu 14.04 LTS is on GCC 4.8.x, and we have to support it
until
>> > end of life.
>> > Resolution: LTS is right around the corner, in 6 more months.
>> >
>> > Issue: Various other platforms have older GCCs as their system
compiler,
>> > and it's annoying to upgrade.
>> > Question: Do any of these not have a port you can install?  For
example,
>> > NetBSD 7 appears to have GCC 5.3 as a port, if DistroWatch is any
>> > indication.  It could be wrong though and I could also be
>> misinterpreting
>> > it.
>> >
>> > Issue: If we're going to make people bootstrap a compiler, we
might as
>> well
>> > go all the way to C++17.
>> > Comment: I'm not opposed.
>> >
>> >
>> > Some questions / comments of my own:
>> >
>> > * Where is this policy about Ubuntu and LTS documented?  Does this
mean,
>> > for example, that we will not be able to use C++17 until 2023
(16.04 LTS
>> > has only GCC 5.3.1)?  That seems a bit unreasonable.  And
there's no
>> > guarantee that 18.04 LTS will even have GCC 7 or higher either, so
it
>> could
>> > be 2025 or 2027.
>> >
>> > * We've asked people in the past to build a modern toolchain. 
For
>> example,
>> > we did it with C++11 and Ubuntu 12.04 LTS.  Is C++17 compelling
enough
>> to
>> > justify this again?
>> >
>> > * GCC 4.9 probably isn't sufficient to justify an increase for
anyone,
>> as
>> > it lacks two of the more sought-after features of C++14 (variable
>> templates
>> > and generalized constexpr).  So IMO we should require a bump to
GCC 5 or
>> > higher, or not at all.
>> >
>> > * Clang 6 supports all of C++20, and it builds with only C++11, so
we
>> > shouldn't have to worry too much about the problem of needing
to "daisy
>> > chain" compilers to finally get the latest version of LLVM
building.
>>  "GCC
>> > 4.8 -> Clang 6 - > Clang ToT" should hold up through
C++1z.
>> >
>> > * While we obviously can't be tied to the versioning of every
single
>> distro
>> > out there, some are "bigger" than others.  Which are big
enough that
>> > warrant serious consideration?  The ones I found are (and I did my
best
>> to
>> > aggregate all this, but please correct me if anything is incorrect
or
>> > misrepresented):
>> >
>> > OpenBSD - Ships with GCC 4.2.1 anyway.  They are already having to
>> > bootstrap something, so the proposal here does not change
anything,
>> because
>> > even current LLVM doesn't compile with GCC 4.2.1
>> >
>> > CentOS & RHEL - No version of Distro, including trunk, has GCC
>= 4.8.5
>> > (are there ports?)
>> >
>> > Debian - Minimum version 9 for GCC >= 5  (are there ports for
earlier
>> > releases?)
>> >
>> > Fedora - Minimum version 24 for GCC >= 5, minimum version 26
for GCC >>> 7
>> >
>> > Ubuntu - Minimum LTS 16.04 for GCC >= 5
>> >
>> > NetBSD - Version 7 has GCC 4.8.4 by default, but contains port for
5.3.0
>> >
>> > FreeBSD - Minimum Version 11 for GCC >= 5
>> >
>> > So, thoughts?
>> >
>> >
>> > [1] - Note that we'd need to wait a few more revs for MSVC
before
>> allowing
>> > C++17, but given that it's becoming easier and easier to bump
the
>> minimum
>> > MSVC version, I'm discounting this as a factor, as MSVC will
not really
>> be
>> > the bottleneck in any real sense.
>> >
>> > On Tue, Oct 4, 2016 at 2:15 PM Mehdi Amini <mehdi.amini at
apple.com>
>> wrote:
>> >
>> >>
>> >> On Oct 4, 2016, at 2:10 PM, Reid Kleckner <rnk at
google.com> wrote:
>> >>
>> >> On Tue, Oct 4, 2016 at 11:58 AM, Mehdi Amini <mehdi.amini
at apple.com
>> >
>> >> wrote:
>> >>
>> >>>
>> >>> On Oct 4, 2016, at 8:40 AM, Reid Kleckner via llvm-dev
<
>> >>> llvm-dev at lists.llvm.org> wrote:
>> >>>
>> >>> On Tue, Oct 4, 2016 at 8:29 AM, Zachary Turner <zturner
at google.com
>> >
>> >>> wrote:
>> >>>>
>> >>>> I ask because many of these LTS distros are
notoriously slow at
>> updating
>> >>>> their packages. While some people may think C++14
doesn't provide
>> enough
>> >>>> bang for the buck to justify bumping to GCC 4.9, C++17
definitely
>> does. But
>> >>>> at that point we're going to be talking about GCC
6.1 or 6.2, which
>> is
>> >>>> going to be significantly harder unless we want to
wait 5-7 years,
>> and I
>> >>>> suspect people won't.
>> >>>>
>> >>>
>> >>> If by "notoriously slow" you mean they don't
bump their toolchain
>> >>> versions at all, then yeah. We just wait until the LTS
release is at
>> >>> end-of-life before dropping it.
>> >>>
>> >>>
>> >>> That’s the first time I read about this policy: we support
every linux
>> >>> LTS distribution till their end-of-life? Only Ubuntu? Do
you have a
>> pointer
>> >>> where it is documented / discussed?
>> >>> (Note that Ubuntu LTS is 5 years AFAIK.)
>> >>>
>> >>
>> >> Sorry, I didn't mean to refer to the LTS support lifetime.
I just
>> meant we
>> >> support the last LTS until we can reasonably expect users to
have
>> upgraded
>> >> to the new one. If there's an LTS release every two years,
then we
>> want to
>> >> keep supporting them for at least three years to give people a
year to
>> >> upgrade.
>> >>
>> >>
>> >> OK, got it.
>> >>
>> >> Thanks for clarifying!
>> >>
>> >> Mehdi
>> >>
>> >>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>> _______________________________________________
>> 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
>>
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180510/f27911ed/attachment.html>

Evgeny Astigeevich via llvm-dev

2018-May-11 09:12 UTC

head link

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

Hi Chandler,

Yes, this is a known issue with libstdc++ ABI.
What if we use _GLIBCXX_USE_CXX11_ABI=0 as recommended by
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html ?
Gcc also provides the -Wabi-tag option to detect library ABI issues.

Thanks,
Evgeny

From: Chandler Carruth <chandlerc at google.com>
Date: Thursday, 10 May 2018 at 21:50
To: JF Bastien <jfbastien at apple.com>
Cc: Evgeny Astigeevich <Evgeny.Astigeevich at arm.com>, llvm-dev
<llvm-dev at lists.llvm.org>, nd <nd at arm.com>
Subject: Re: [llvm-dev] Using C++14 code in LLVM

Last time this came up, there were a lot of people that were stuck on GCC 4.9
due to ABI reasons. I think forcing that upgrade is going to be the most
disruptive part of this, and I think that will really need a decent amount of
time. =[

On Thu, May 10, 2018 at 2:26 PM JF Bastien via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:

On May 10, 2018, at 12:25 PM, Evgeny Astigeevich via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:

Hi,

IMHO, it’s a good idea to move to C++14 first.

What do you think about doing this by two phases:

Phase1: require GCC >= 5 but build in C++11 mode (this will give time to
adapt build infrastructure to a new gcc)
Phase2: switch to C++14

Sounds reasonable, here’s a patch:
https://reviews.llvm.org/D46723

Thanks,
Evgeny

From: llvm-dev <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces
at lists.llvm.org>> on behalf of Reid Kleckner via llvm-dev <llvm-dev
at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>
Reply-To: Reid Kleckner <rnk at google.com<mailto:rnk at
google.com>>
Date: Thursday, 10 May 2018 at 19:50
To: Zachary Turner <zturner at google.com<mailto:zturner at
google.com>>
Cc: llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at
lists.llvm.org>>
Subject: Re: [llvm-dev] Using C++14 code in LLVM

The easy way not to have a three year discussion is to not worry about it for
another three years. :)

So, I think we should take the easy things on the table and just move to C++14
in the near future. It's just a matter of dropping support for building on
distros that only have GCC <5 (aka Trusty, which is from 2014 itself).
Let's do that and call it a day.

---
Aside: I'm always kind of amused by talk of moving to the next
"standard version" when the reality is that every C++ project is
always held back by the compilers and standard libraries that they actually use
in practice. We say LLVM requires C++11 which mandates a working set of
threading primitives, but in practice those don't exist on some platforms
that people would like us to support, so we end up maintaining the
LLVM_ENABLE_THREADING=0 build for them.

It seems more practical to simply list the minimum versions of supported
toolchains that are commonly used to build, i.e. GCC 5, MSVC 2015, Clang 3.N,
libc++ 3.N, libstdc++ 3.N, etc.

On Thu, May 10, 2018 at 11:36 AM Zachary Turner via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
If it's the only thing we can agree then I'll take it, but I just worry
that 3 years from now we're going to start another 3 year discussion, so
that any actual move to C++17 would end up taking double the time.

Are the issues specific to C++17 additions to the standard library?  What if you
allow C++17 language features but not C++17 library features?  I'm guessing
this is too simple though and isn't sufficient to avoid the problems (which
I don't know anything about, so you'll have to enlighten me)?

On Thu, May 10, 2018 at 11:28 AM JF Bastien <jfbastien at
apple.com<mailto:jfbastien at apple.com>> wrote:

On May 10, 2018, at 11:22 AM, Zachary Turner <zturner at
google.com<mailto:zturner at google.com>> wrote:

Windows has never been the issue.  Honestly, MSVC on Windows is "fully
C++17 conformant" [1].

The issue has and always will be GCC.  Given that a bump in any version of GCC
has been (and will remain) difficult for some time, I propose that we skip C++14
and move to 17.  We don't want to have a multi-year disccusion about this
again any time soon, and from what I gather, nobody has any more reservations
about moving to C++17 than they do about moving to C++14.  They only have
reservations about moving to anything at all.  So if we're gonna move, we
should go all the way.

WebKit’s move to C++17 hasn’t been super smooth because of GCC / libstdc++
issues in both GCC 6 and GCC 7. It’s all fixable, but given LLVM's slow move
out of C++11 I’d rather get C++14 now rather than a painful transition to C++17
that drags on as we discover issues.

Just my 2c.

[1]
https://blogs.msdn.microsoft.com/vcblog/2018/05/07/announcing-msvc-conforms-to-the-c-standard/

On Thu, May 10, 2018 at 11:18 AM Eric Christopher <echristo at
gmail.com<mailto:echristo at gmail.com>> wrote:
Once again, I'm totally down for this and think we should do it. I worry
about windows, but ...

Zach: How's windows c++14 support looking?

-eric

On Thu, May 10, 2018 at 10:01 AM JF Bastien via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Hi folks!

Six more months have come and gone, and maybe we could move LLVM to C++14 now?

The issues I picked out from the last discussion:
1.       Some folks want an official policy about compiler support before
updating the standard version we use.
2.       Worries about which GCC version is available in which distro.
3.       Worries about MSVC.

Instead of rehashing the compiler per distro surveys from previous discussion,
and instead of talking bootstrap, let me offer three data points:
•         WebKit is moving to
C++17<https://lists.webkit.org/pipermail/webkit-dev/2018-March/029922.html>
(from C++14) right now †
•         Chromium started moving to
C++14<https://groups.google.com/a/chromium.org/d/msg/cxx/ow7hmdDm4yw/eV6KWL2yAQAJ>
in August of last year
•         Firefox uses some
C++14<https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code>
What I get from this data: if your distro bundles a modern web browser, it
already builds some C++14, somehow.

The LLVM community has been talking about this for a while now, and I’m not
aware of a policy coming to light. I don’t think we need a policy given the
above data. So how about we… just kinda... move LLVM to C++14?

Thanks!

JF

† the move to C++17 is very painful, but 14 has been working great in WebKit for
quite a long time.

> Last time we discussed this, the consensus was "I think we can survive
> another year without generalized constexpr and variable templates".
>
> Well, we did indeed survive.   And it's been exactly a year!  So
naturally,
> it only makes sense to revive this :)
>
>
>
> There's an active conversation going on in IRC right now, and it seems
like
> there is more desire than there was last year.
>
> What are the main gains from allowing C++14?
> * Variable templates
> * Generalized constexpr
> * Return-type Deduction
> * Generic Lambdas
> * std::make_unique<> (the source of many build bot breakages)
>
>
> What are the main gains from allowing C++17?  [1]
> * [[nodiscard]] attribute
> * structured bindings
> * constexpr-if
> * guaranteed copy elision
> * numerous new library types: optional, string_view, variant, byte,
> * numerous new algorithms: parallel algorithms, too many to list
> * Probably some more, but I just tried to hit the biggest ones.
>
>
> First, it seems like if we want to enable C++14 we need GCC >= 5.
> And if we want to enable C++17 we need GCC >= 7.
>
> With that out of the way, here were some of the issues that were raised
> last time:
>
> Issue: Ubuntu 14.04 LTS is on GCC 4.8.x, and we have to support it until
> end of life.
> Resolution: LTS is right around the corner, in 6 more months.
>
> Issue: Various other platforms have older GCCs as their system compiler,
> and it's annoying to upgrade.
> Question: Do any of these not have a port you can install?  For example,
> NetBSD 7 appears to have GCC 5.3 as a port, if DistroWatch is any
> indication.  It could be wrong though and I could also be misinterpreting
> it.
>
> Issue: If we're going to make people bootstrap a compiler, we might as
well
> go all the way to C++17.
> Comment: I'm not opposed.
>
>
> Some questions / comments of my own:
>
> * Where is this policy about Ubuntu and LTS documented?  Does this mean,
> for example, that we will not be able to use C++17 until 2023 (16.04 LTS
> has only GCC 5.3.1)?  That seems a bit unreasonable.  And there's no
> guarantee that 18.04 LTS will even have GCC 7 or higher either, so it could
> be 2025 or 2027.
>
> * We've asked people in the past to build a modern toolchain.  For
example,
> we did it with C++11 and Ubuntu 12.04 LTS.  Is C++17 compelling enough to
> justify this again?
>
> * GCC 4.9 probably isn't sufficient to justify an increase for anyone,
as
> it lacks two of the more sought-after features of C++14 (variable templates
> and generalized constexpr).  So IMO we should require a bump to GCC 5 or
> higher, or not at all.
>
> * Clang 6 supports all of C++20, and it builds with only C++11, so we
> shouldn't have to worry too much about the problem of needing to
"daisy
> chain" compilers to finally get the latest version of LLVM building. 
"GCC
> 4.8 -> Clang 6 - > Clang ToT" should hold up through C++1z.
>
> * While we obviously can't be tied to the versioning of every single
distro
> out there, some are "bigger" than others.  Which are big enough
that
> warrant serious consideration?  The ones I found are (and I did my best to
> aggregate all this, but please correct me if anything is incorrect or
> misrepresented):
>
> OpenBSD - Ships with GCC 4.2.1 anyway.  They are already having to
> bootstrap something, so the proposal here does not change anything, because
> even current LLVM doesn't compile with GCC 4.2.1
>
> CentOS & RHEL - No version of Distro, including trunk, has GCC >=
4.8.5
> (are there ports?)
>
> Debian - Minimum version 9 for GCC >= 5  (are there ports for earlier
> releases?)
>
> Fedora - Minimum version 24 for GCC >= 5, minimum version 26 for GCC
>= 7
>
> Ubuntu - Minimum LTS 16.04 for GCC >= 5
>
> NetBSD - Version 7 has GCC 4.8.4 by default, but contains port for 5.3.0
>
> FreeBSD - Minimum Version 11 for GCC >= 5
>
> So, thoughts?
>
>
> [1] - Note that we'd need to wait a few more revs for MSVC before
allowing
> C++17, but given that it's becoming easier and easier to bump the
minimum
> MSVC version, I'm discounting this as a factor, as MSVC will not really
be
> the bottleneck in any real sense.
>
> On Tue, Oct 4, 2016 at 2:15 PM Mehdi Amini <mehdi.amini at
apple.com<http://apple.com/>> wrote:
>
>>
>> On Oct 4, 2016, at 2:10 PM, Reid Kleckner <rnk at
google.com<http://google.com/>> wrote:
>>
>> On Tue, Oct 4, 2016 at 11:58 AM, Mehdi Amini <mehdi.amini at
apple.com<http://apple.com/>>
>> wrote:
>>
>>>
>>> On Oct 4, 2016, at 8:40 AM, Reid Kleckner via llvm-dev <
>>> llvm-dev at lists.llvm.org<http://lists.llvm.org/>> wrote:
>>>
>>> On Tue, Oct 4, 2016 at 8:29 AM, Zachary Turner <zturner at
google.com<http://google.com/>>
>>> wrote:
>>>>
>>>> I ask because many of these LTS distros are notoriously slow at
updating
>>>> their packages. While some people may think C++14 doesn't
provide enough
>>>> bang for the buck to justify bumping to GCC 4.9, C++17
definitely does. But
>>>> at that point we're going to be talking about GCC 6.1 or
6.2, which is
>>>> going to be significantly harder unless we want to wait 5-7
years, and I
>>>> suspect people won't.
>>>>
>>>
>>> If by "notoriously slow" you mean they don't bump
their toolchain
>>> versions at all, then yeah. We just wait until the LTS release is
at
>>> end-of-life before dropping it.
>>>
>>>
>>> That’s the first time I read about this policy: we support every
linux
>>> LTS distribution till their end-of-life? Only Ubuntu? Do you have a
pointer
>>> where it is documented / discussed?
>>> (Note that Ubuntu LTS is 5 years AFAIK.)
>>>
>>
>> Sorry, I didn't mean to refer to the LTS support lifetime. I just
meant we
>> support the last LTS until we can reasonably expect users to have
upgraded
>> to the new one. If there's an LTS release every two years, then we
want to
>> keep supporting them for at least three years to give people a year to
>> upgrade.
>>
>>
>> OK, got it.
>>
>> Thanks for clarifying!
>>
>> Mehdi
>>
>>_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180511/a8541946/attachment-0001.html>

Dimitry Andric via llvm-dev

2018-May-11 11:36 UTC

head link

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

And what will be the lowest version of clang that will be supported for
building?  FreeBSD's oldest supported OS release is still stuck with clang
3.4 (and a corresponding copy of libc++), which has some support for C++14,
although it's still called c++1y there, but probably not C++17.  Also, it
isn't exactly clear from which llvm/clang release C++17 is fully supported.

-Dimitry
> On 10 May 2018, at 22:50, Chandler Carruth via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Last time this came up, there were a lot of people that were stuck on GCC
4.9 due to ABI reasons. I think forcing that upgrade is going to be the most
disruptive part of this, and I think that will really need a decent amount of
time. =[
> 
> On Thu, May 10, 2018 at 2:26 PM JF Bastien via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> 
>> On May 10, 2018, at 12:25 PM, Evgeny Astigeevich via llvm-dev
<llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
wrote:
>> 
>> Hi,
>> 
>> IMHO, it’s a good idea to move to C++14 first.
>> 
>> What do you think about doing this by two phases:
>> 
>> Phase1: require GCC >= 5 but build in C++11 mode (this will give
time to adapt build infrastructure to a new gcc)
>> Phase2: switch to C++14
> 
> Sounds reasonable, here’s a patch:
> https://reviews.llvm.org/D46723 <https://reviews.llvm.org/D46723>
> 
> 
>> Thanks,
>> Evgeny
>> 
>> 
>> 
>> From: llvm-dev <llvm-dev-bounces at lists.llvm.org
<mailto:llvm-dev-bounces at lists.llvm.org>> on behalf of Reid Kleckner
via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>>
>> Reply-To: Reid Kleckner <rnk at google.com <mailto:rnk at
google.com>>
>> Date: Thursday, 10 May 2018 at 19:50
>> To: Zachary Turner <zturner at google.com <mailto:zturner at
google.com>>
>> Cc: llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>>
>> Subject: Re: [llvm-dev] Using C++14 code in LLVM
>> 
>> The easy way not to have a three year discussion is to not worry about
it for another three years. :)
>> 
>> So, I think we should take the easy things on the table and just move
to C++14 in the near future. It's just a matter of dropping support for
building on distros that only have GCC <5 (aka Trusty, which is from 2014
itself). Let's do that and call it a day.
>> 
>> ---
>> Aside: I'm always kind of amused by talk of moving to the next
"standard version" when the reality is that every C++ project is
always held back by the compilers and standard libraries that they actually use
in practice. We say LLVM requires C++11 which mandates a working set of
threading primitives, but in practice those don't exist on some platforms
that people would like us to support, so we end up maintaining the
LLVM_ENABLE_THREADING=0 build for them.
>> 
>> It seems more practical to simply list the minimum versions of
supported toolchains that are commonly used to build, i.e. GCC 5, MSVC 2015,
Clang 3.N, libc++ 3.N, libstdc++ 3.N, etc.
>> 
>> On Thu, May 10, 2018 at 11:36 AM Zachary Turner via llvm-dev
<llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
wrote:
>>> If it's the only thing we can agree then I'll take it, but
I just worry that 3 years from now we're going to start another 3 year
discussion, so that any actual move to C++17 would end up taking double the
time.
>>> 
>>> Are the issues specific to C++17 additions to the standard library?
What if you allow C++17 language features but not C++17 library features? 
I'm guessing this is too simple though and isn't sufficient to avoid the
problems (which I don't know anything about, so you'll have to enlighten
me)?
>>> 
>>> On Thu, May 10, 2018 at 11:28 AM JF Bastien <jfbastien at
apple.com <mailto:jfbastien at apple.com>> wrote:
>>>> 
>>>> 
>>>>> On May 10, 2018, at 11:22 AM, Zachary Turner <zturner at
google.com <mailto:zturner at google.com>> wrote:
>>>>> 
>>>>> Windows has never been the issue.  Honestly, MSVC on
Windows is "fully C++17 conformant" [1].
>>>>> 
>>>>> The issue has and always will be GCC.  Given that a bump in
any version of GCC has been (and will remain) difficult for some time, I propose
that we skip C++14 and move to 17.  We don't want to have a multi-year
disccusion about this again any time soon, and from what I gather, nobody has
any more reservations about moving to C++17 than they do about moving to C++14. 
They only have reservations about moving to anything at all.  So if we're
gonna move, we should go all the way.
>>>> 
>>>> WebKit’s move to C++17 hasn’t been super smooth because of GCC
/ libstdc++ issues in both GCC 6 and GCC 7. It’s all fixable, but given
LLVM's slow move out of C++11 I’d rather get C++14 now rather than a painful
transition to C++17 that drags on as we discover issues.
>>>> 
>>>> 
>>>> 
>>>>> Just my 2c.
>>>>> 
>>>>> [1]
https://blogs.msdn.microsoft.com/vcblog/2018/05/07/announcing-msvc-conforms-to-the-c-standard/
<https://blogs.msdn.microsoft.com/vcblog/2018/05/07/announcing-msvc-conforms-to-the-c-standard/>
>>>>> 
>>>>> On Thu, May 10, 2018 at 11:18 AM Eric Christopher
<echristo at gmail.com <mailto:echristo at gmail.com>> wrote:
>>>>>> Once again, I'm totally down for this and think we
should do it. I worry about windows, but ...
>>>>>> 
>>>>>> Zach: How's windows c++14 support looking?
>>>>>> 
>>>>>> -eric
>>>>>> 
>>>>>> On Thu, May 10, 2018 at 10:01 AM JF Bastien via
llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
>>>>>>> Hi folks!
>>>>>>> 
>>>>>>> Six more months have come and gone, and maybe we
could move LLVM to C++14 now?
>>>>>>> 
>>>>>>> The issues I picked out from the last discussion:
>>>>>>> 1.       Some folks want an official policy about
compiler support before updating the standard version we use.
>>>>>>> 2.       Worries about which GCC version is
available in which distro.
>>>>>>> 3.       Worries about MSVC.
>>>>>>> 
>>>>>>> Instead of rehashing the compiler per distro
surveys from previous discussion, and instead of talking bootstrap, let me offer
three data points:
>>>>>>> ·         WebKit is moving to C++17
<https://lists.webkit.org/pipermail/webkit-dev/2018-March/029922.html>
(from C++14) right now †
>>>>>>> ·         Chromium started moving to C++14
<https://groups.google.com/a/chromium.org/d/msg/cxx/ow7hmdDm4yw/eV6KWL2yAQAJ>
in August of last year
>>>>>>> ·         Firefox uses some C++14
<https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code>
>>>>>>> What I get from this data: if your distro bundles a
modern web browser, it already builds some C++14, somehow.
>>>>>>> 
>>>>>>> The LLVM community has been talking about this for
a while now, and I’m not aware of a policy coming to light. I don’t think we
need a policy given the above data. So how about we… just kinda... move LLVM to
C++14?
>>>>>>> 
>>>>>>> 
>>>>>>> Thanks!
>>>>>>> 
>>>>>>> JF
>>>>>>> 
>>>>>>> 
>>>>>>> † the move to C++17 is very painful, but 14 has
been working great in WebKit for quite a long time.
>>>>>>> 
>>>>>>> 
>>>>>>> > Last time we discussed this, the consensus was
"I think we can survive
>>>>>>> > another year without generalized constexpr and
variable templates".
>>>>>>> >
>>>>>>> > Well, we did indeed survive.   And it's
been exactly a year!  So naturally,
>>>>>>> > it only makes sense to revive this :)
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > There's an active conversation going on in
IRC right now, and it seems like
>>>>>>> > there is more desire than there was last year.
>>>>>>> >
>>>>>>> > What are the main gains from allowing C++14?
>>>>>>> > * Variable templates
>>>>>>> > * Generalized constexpr
>>>>>>> > * Return-type Deduction
>>>>>>> > * Generic Lambdas
>>>>>>> > * std::make_unique<> (the source of many
build bot breakages)
>>>>>>> >
>>>>>>> >
>>>>>>> > What are the main gains from allowing C++17? 
[1]
>>>>>>> > * [[nodiscard]] attribute
>>>>>>> > * structured bindings
>>>>>>> > * constexpr-if
>>>>>>> > * guaranteed copy elision
>>>>>>> > * numerous new library types: optional,
string_view, variant, byte,
>>>>>>> > * numerous new algorithms: parallel
algorithms, too many to list
>>>>>>> > * Probably some more, but I just tried to hit
the biggest ones.
>>>>>>> >
>>>>>>> >
>>>>>>> > First, it seems like if we want to enable
C++14 we need GCC >= 5.
>>>>>>> > And if we want to enable C++17 we need GCC
>= 7.
>>>>>>> >
>>>>>>> > With that out of the way, here were some of
the issues that were raised
>>>>>>> > last time:
>>>>>>> >
>>>>>>> > Issue: Ubuntu 14.04 LTS is on GCC 4.8.x, and
we have to support it until
>>>>>>> > end of life.
>>>>>>> > Resolution: LTS is right around the corner, in
6 more months.
>>>>>>> >
>>>>>>> > Issue: Various other platforms have older GCCs
as their system compiler,
>>>>>>> > and it's annoying to upgrade.
>>>>>>> > Question: Do any of these not have a port you
can install?  For example,
>>>>>>> > NetBSD 7 appears to have GCC 5.3 as a port, if
DistroWatch is any
>>>>>>> > indication.  It could be wrong though and I
could also be misinterpreting
>>>>>>> > it.
>>>>>>> >
>>>>>>> > Issue: If we're going to make people
bootstrap a compiler, we might as well
>>>>>>> > go all the way to C++17.
>>>>>>> > Comment: I'm not opposed.
>>>>>>> >
>>>>>>> >
>>>>>>> > Some questions / comments of my own:
>>>>>>> >
>>>>>>> > * Where is this policy about Ubuntu and LTS
documented?  Does this mean,
>>>>>>> > for example, that we will not be able to use
C++17 until 2023 (16.04 LTS
>>>>>>> > has only GCC 5.3.1)?  That seems a bit
unreasonable.  And there's no
>>>>>>> > guarantee that 18.04 LTS will even have GCC 7
or higher either, so it could
>>>>>>> > be 2025 or 2027.
>>>>>>> >
>>>>>>> > * We've asked people in the past to build
a modern toolchain.  For example,
>>>>>>> > we did it with C++11 and Ubuntu 12.04 LTS.  Is
C++17 compelling enough to
>>>>>>> > justify this again?
>>>>>>> >
>>>>>>> > * GCC 4.9 probably isn't sufficient to
justify an increase for anyone, as
>>>>>>> > it lacks two of the more sought-after features
of C++14 (variable templates
>>>>>>> > and generalized constexpr).  So IMO we should
require a bump to GCC 5 or
>>>>>>> > higher, or not at all.
>>>>>>> >
>>>>>>> > * Clang 6 supports all of C++20, and it builds
with only C++11, so we
>>>>>>> > shouldn't have to worry too much about the
problem of needing to "daisy
>>>>>>> > chain" compilers to finally get the
latest version of LLVM building.  "GCC
>>>>>>> > 4.8 -> Clang 6 - > Clang ToT"
should hold up through C++1z.
>>>>>>> >
>>>>>>> > * While we obviously can't be tied to the
versioning of every single distro
>>>>>>> > out there, some are "bigger" than
others.  Which are big enough that
>>>>>>> > warrant serious consideration?  The ones I
found are (and I did my best to
>>>>>>> > aggregate all this, but please correct me if
anything is incorrect or
>>>>>>> > misrepresented):
>>>>>>> >
>>>>>>> > OpenBSD - Ships with GCC 4.2.1 anyway.  They
are already having to
>>>>>>> > bootstrap something, so the proposal here does
not change anything, because
>>>>>>> > even current LLVM doesn't compile with GCC
4.2.1
>>>>>>> >
>>>>>>> > CentOS & RHEL - No version of Distro,
including trunk, has GCC >= 4.8.5
>>>>>>> > (are there ports?)
>>>>>>> >
>>>>>>> > Debian - Minimum version 9 for GCC >= 5 
(are there ports for earlier
>>>>>>> > releases?)
>>>>>>> >
>>>>>>> > Fedora - Minimum version 24 for GCC >= 5,
minimum version 26 for GCC >= 7
>>>>>>> >
>>>>>>> > Ubuntu - Minimum LTS 16.04 for GCC >= 5
>>>>>>> >
>>>>>>> > NetBSD - Version 7 has GCC 4.8.4 by default,
but contains port for 5.3.0
>>>>>>> >
>>>>>>> > FreeBSD - Minimum Version 11 for GCC >= 5
>>>>>>> >
>>>>>>> > So, thoughts?
>>>>>>> >
>>>>>>> >
>>>>>>> > [1] - Note that we'd need to wait a few
more revs for MSVC before allowing
>>>>>>> > C++17, but given that it's becoming easier
and easier to bump the minimum
>>>>>>> > MSVC version, I'm discounting this as a
factor, as MSVC will not really be
>>>>>>> > the bottleneck in any real sense.
>>>>>>> >
>>>>>>> > On Tue, Oct 4, 2016 at 2:15 PM Mehdi Amini
<mehdi.amini at apple.com <http://apple.com/>> wrote:
>>>>>>> >
>>>>>>> >>
>>>>>>> >> On Oct 4, 2016, at 2:10 PM, Reid Kleckner
<rnk at google.com <http://google.com/>> wrote:
>>>>>>> >>
>>>>>>> >> On Tue, Oct 4, 2016 at 11:58 AM, Mehdi
Amini <mehdi.amini at apple.com <http://apple.com/>>
>>>>>>> >> wrote:
>>>>>>> >>
>>>>>>> >>>
>>>>>>> >>> On Oct 4, 2016, at 8:40 AM, Reid
Kleckner via llvm-dev <
>>>>>>> >>> llvm-dev at lists.llvm.org
<http://lists.llvm.org/>> wrote:
>>>>>>> >>>
>>>>>>> >>> On Tue, Oct 4, 2016 at 8:29 AM,
Zachary Turner <zturner at google.com <http://google.com/>>
>>>>>>> >>> wrote:
>>>>>>> >>>>
>>>>>>> >>>> I ask because many of these LTS
distros are notoriously slow at updating
>>>>>>> >>>> their packages. While some people
may think C++14 doesn't provide enough
>>>>>>> >>>> bang for the buck to justify
bumping to GCC 4.9, C++17 definitely does. But
>>>>>>> >>>> at that point we're going to
be talking about GCC 6.1 or 6.2, which is
>>>>>>> >>>> going to be significantly harder
unless we want to wait 5-7 years, and I
>>>>>>> >>>> suspect people won't.
>>>>>>> >>>>
>>>>>>> >>>
>>>>>>> >>> If by "notoriously slow" you
mean they don't bump their toolchain
>>>>>>> >>> versions at all, then yeah. We just
wait until the LTS release is at
>>>>>>> >>> end-of-life before dropping it.
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>> That’s the first time I read about
this policy: we support every linux
>>>>>>> >>> LTS distribution till their
end-of-life? Only Ubuntu? Do you have a pointer
>>>>>>> >>> where it is documented / discussed?
>>>>>>> >>> (Note that Ubuntu LTS is 5 years
AFAIK.)
>>>>>>> >>>
>>>>>>> >>
>>>>>>> >> Sorry, I didn't mean to refer to the
LTS support lifetime. I just meant we
>>>>>>> >> support the last LTS until we can
reasonably expect users to have upgraded
>>>>>>> >> to the new one. If there's an LTS
release every two years, then we want to
>>>>>>> >> keep supporting them for at least three
years to give people a year to
>>>>>>> >> upgrade.
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> OK, got it.
>>>>>>> >>
>>>>>>> >> Thanks for clarifying!
>>>>>>> >>
>>>>>>> >> Mehdi
>>>>>>> >>
>>>>>>> >>
>>>>>>> _______________________________________________
>>>>>>> LLVM Developers mailing list
>>>>>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>>>>>>>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>_______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180511/d579bb84/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 223 bytes
Desc: Message signed with OpenPGP
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180511/d579bb84/attachment.sig>

Adrien Guinet via llvm-dev

2018-May-11 13:17 UTC

head link

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

On 05/10/2018 10:50 PM, Chandler Carruth via llvm-dev
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. =[
> 

Another similar thing to consider is for people building LLVM within
Python extensions (llvmlite, dragonffi, cppyy and others!). Python
wheels under Linux are built using a fixed CentOS version. A new ABI
(manylinux2010) appeared recently
(https://www.python.org/dev/peps/pep-0571/) that uses CentOS 6. I don't
know which C++ library is used here, but if it is too old, it could also
be an issue !

My 2 cents.

-- 
Adrien.

JF Bastien via llvm-dev

2018-May-11 16:16 UTC

head link

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

> On May 11, 2018, at 4:36 AM, Dimitry Andric <dimitry at andric.com>
wrote:
> 
> And what will be the lowest version of clang that will be supported for
building?  FreeBSD's oldest supported OS release is still stuck with clang
3.4 (and a corresponding copy of libc++), which has some support for C++14,
although it's still called c++1y there, but probably not C++17.  Also, it
isn't exactly clear from which llvm/clang release C++17 is fully supported.
I initially proposed 3.4 because it has ~all C++14 language features (albeit
under std=c++1y), but someone on the patch asked for 3.5 so the flags would be
simpler. Your use case seems to outweigh the one made about simplicity of flags.

One thing I still want to check is how buggy each compiler’s support for C++14
is. We can mandate 3.4 all we want, but if it mishandles C++14 features we’re
much worst off.

For reference, the patch is https://reviews.llvm.org/D46723
<https://reviews.llvm.org/D46723>


> -Dimitry
> 
>> On 10 May 2018, at 22:50, Chandler Carruth via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> 
>> Last time this came up, there were a lot of people that were stuck on
GCC 4.9 due to ABI reasons. I think forcing that upgrade is going to be the most
disruptive part of this, and I think that will really need a decent amount of
time. =[
>> 
>> On Thu, May 10, 2018 at 2:26 PM JF Bastien via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> 
>>> On May 10, 2018, at 12:25 PM, Evgeny Astigeevich via llvm-dev
<llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
wrote:
>>> 
>>> Hi,
>>>  
>>> IMHO, it’s a good idea to move to C++14 first.
>>>  
>>> What do you think about doing this by two phases:
>>>  
>>> Phase1: require GCC >= 5 but build in C++11 mode (this will give
time to adapt build infrastructure to a new gcc)
>>> Phase2: switch to C++14
>> 
>> Sounds reasonable, here’s a patch:
>> https://reviews.llvm.org/D46723 <https://reviews.llvm.org/D46723>
>> 
>> 
>>> Thanks,
>>> Evgeny
>>>  
>>>  
>>>  
>>> From: llvm-dev <llvm-dev-bounces at lists.llvm.org
<mailto:llvm-dev-bounces at lists.llvm.org>> on behalf of Reid Kleckner
via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>>
>>> Reply-To: Reid Kleckner <rnk at google.com <mailto:rnk at
google.com>>
>>> Date: Thursday, 10 May 2018 at 19:50
>>> To: Zachary Turner <zturner at google.com <mailto:zturner at
google.com>>
>>> Cc: llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>>
>>> Subject: Re: [llvm-dev] Using C++14 code in LLVM
>>>  
>>> The easy way not to have a three year discussion is to not worry
about it for another three years. :)
>>>  
>>> So, I think we should take the easy things on the table and just
move to C++14 in the near future. It's just a matter of dropping support for
building on distros that only have GCC <5 (aka Trusty, which is from 2014
itself). Let's do that and call it a day.
>>>  
>>> ---
>>> Aside: I'm always kind of amused by talk of moving to the next
"standard version" when the reality is that every C++ project is
always held back by the compilers and standard libraries that they actually use
in practice. We say LLVM requires C++11 which mandates a working set of
threading primitives, but in practice those don't exist on some platforms
that people would like us to support, so we end up maintaining the
LLVM_ENABLE_THREADING=0 build for them.
>>>  
>>> It seems more practical to simply list the minimum versions of
supported toolchains that are commonly used to build, i.e. GCC 5, MSVC 2015,
Clang 3.N, libc++ 3.N, libstdc++ 3.N, etc.
>>>  
>>> On Thu, May 10, 2018 at 11:36 AM Zachary Turner via llvm-dev
<llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
wrote:
>>>> If it's the only thing we can agree then I'll take it,
but I just worry that 3 years from now we're going to start another 3 year
discussion, so that any actual move to C++17 would end up taking double the
time.
>>>>  
>>>> Are the issues specific to C++17 additions to the standard
library?  What if you allow C++17 language features but not C++17 library
features?  I'm guessing this is too simple though and isn't sufficient
to avoid the problems (which I don't know anything about, so you'll have
to enlighten me)?
>>>>  
>>>> On Thu, May 10, 2018 at 11:28 AM JF Bastien <jfbastien at
apple.com <mailto:jfbastien at apple.com>> wrote:
>>>>> 
>>>>> 
>>>>>> On May 10, 2018, at 11:22 AM, Zachary Turner
<zturner at google.com <mailto:zturner at google.com>> wrote:
>>>>>>  
>>>>>> Windows has never been the issue.  Honestly, MSVC on
Windows is "fully C++17 conformant" [1].
>>>>>>  
>>>>>> The issue has and always will be GCC.  Given that a
bump in any version of GCC has been (and will remain) difficult for some time, I
propose that we skip C++14 and move to 17.  We don't want to have a
multi-year disccusion about this again any time soon, and from what I gather,
nobody has any more reservations about moving to C++17 than they do about moving
to C++14.  They only have reservations about moving to anything at all.  So if
we're gonna move, we should go all the way.
>>>>>  
>>>>> WebKit’s move to C++17 hasn’t been super smooth because of
GCC / libstdc++ issues in both GCC 6 and GCC 7. It’s all fixable, but given
LLVM's slow move out of C++11 I’d rather get C++14 now rather than a painful
transition to C++17 that drags on as we discover issues.
>>>>>  
>>>>> 
>>>>> 
>>>>>> Just my 2c.
>>>>>>  
>>>>>> [1]
https://blogs.msdn.microsoft.com/vcblog/2018/05/07/announcing-msvc-conforms-to-the-c-standard/
<https://blogs.msdn.microsoft.com/vcblog/2018/05/07/announcing-msvc-conforms-to-the-c-standard/>
>>>>>>  
>>>>>> On Thu, May 10, 2018 at 11:18 AM Eric Christopher
<echristo at gmail.com <mailto:echristo at gmail.com>> wrote:
>>>>>>> Once again, I'm totally down for this and think
we should do it. I worry about windows, but ...
>>>>>>>  
>>>>>>> Zach: How's windows c++14 support looking?
>>>>>>>  
>>>>>>> -eric
>>>>>>>  
>>>>>>> On Thu, May 10, 2018 at 10:01 AM JF Bastien via
llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
>>>>>>>> Hi folks!
>>>>>>>>  
>>>>>>>> Six more months have come and gone, and maybe
we could move LLVM to C++14 now?
>>>>>>>>  
>>>>>>>> The issues I picked out from the last
discussion:
>>>>>>>> 1.       Some folks want an official policy
about compiler support before updating the standard version we use.
>>>>>>>> 2.       Worries about which GCC version is
available in which distro.
>>>>>>>> 3.       Worries about MSVC.
>>>>>>>>  
>>>>>>>> Instead of rehashing the compiler per distro
surveys from previous discussion, and instead of talking bootstrap, let me offer
three data points:
>>>>>>>> ·         WebKit is moving to C++17
<https://lists.webkit.org/pipermail/webkit-dev/2018-March/029922.html>
(from C++14) right now †
>>>>>>>> ·         Chromium started moving to C++14
<https://groups.google.com/a/chromium.org/d/msg/cxx/ow7hmdDm4yw/eV6KWL2yAQAJ>
in August of last year
>>>>>>>> ·         Firefox uses some C++14
<https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code>
>>>>>>>> What I get from this data: if your distro
bundles a modern web browser, it already builds some C++14, somehow.
>>>>>>>>  
>>>>>>>> The LLVM community has been talking about this
for a while now, and I’m not aware of a policy coming to light. I don’t think we
need a policy given the above data. So how about we… just kinda... move LLVM to
C++14?
>>>>>>>>  
>>>>>>>>  
>>>>>>>> Thanks!
>>>>>>>>  
>>>>>>>> JF
>>>>>>>>  
>>>>>>>>  
>>>>>>>> † the move to C++17 is very painful, but 14 has
been working great in WebKit for quite a long time.
>>>>>>>>  
>>>>>>>>  
>>>>>>>> > Last time we discussed this, the consensus
was "I think we can survive
>>>>>>>> > another year without generalized constexpr
and variable templates".
>>>>>>>> > 
>>>>>>>> > Well, we did indeed survive.   And
it's been exactly a year!  So naturally,
>>>>>>>> > it only makes sense to revive this :)
>>>>>>>> > 
>>>>>>>> > 
>>>>>>>> > 
>>>>>>>> > There's an active conversation going
on in IRC right now, and it seems like
>>>>>>>> > there is more desire than there was last
year.
>>>>>>>> > 
>>>>>>>> > What are the main gains from allowing
C++14?
>>>>>>>> > * Variable templates
>>>>>>>> > * Generalized constexpr
>>>>>>>> > * Return-type Deduction
>>>>>>>> > * Generic Lambdas
>>>>>>>> > * std::make_unique<> (the source of
many build bot breakages)
>>>>>>>> > 
>>>>>>>> > 
>>>>>>>> > What are the main gains from allowing
C++17?  [1]
>>>>>>>> > * [[nodiscard]] attribute
>>>>>>>> > * structured bindings
>>>>>>>> > * constexpr-if
>>>>>>>> > * guaranteed copy elision
>>>>>>>> > * numerous new library types: optional,
string_view, variant, byte,
>>>>>>>> > * numerous new algorithms: parallel
algorithms, too many to list
>>>>>>>> > * Probably some more, but I just tried to
hit the biggest ones.
>>>>>>>> > 
>>>>>>>> > 
>>>>>>>> > First, it seems like if we want to enable
C++14 we need GCC >= 5.
>>>>>>>> > And if we want to enable C++17 we need GCC
>= 7.
>>>>>>>> > 
>>>>>>>> > With that out of the way, here were some
of the issues that were raised
>>>>>>>> > last time:
>>>>>>>> > 
>>>>>>>> > Issue: Ubuntu 14.04 LTS is on GCC 4.8.x,
and we have to support it until
>>>>>>>> > end of life.
>>>>>>>> > Resolution: LTS is right around the
corner, in 6 more months.
>>>>>>>> > 
>>>>>>>> > Issue: Various other platforms have older
GCCs as their system compiler,
>>>>>>>> > and it's annoying to upgrade.
>>>>>>>> > Question: Do any of these not have a port
you can install?  For example,
>>>>>>>> > NetBSD 7 appears to have GCC 5.3 as a
port, if DistroWatch is any
>>>>>>>> > indication.  It could be wrong though and
I could also be misinterpreting
>>>>>>>> > it.
>>>>>>>> > 
>>>>>>>> > Issue: If we're going to make people
bootstrap a compiler, we might as well
>>>>>>>> > go all the way to C++17.
>>>>>>>> > Comment: I'm not opposed.
>>>>>>>> > 
>>>>>>>> > 
>>>>>>>> > Some questions / comments of my own:
>>>>>>>> > 
>>>>>>>> > * Where is this policy about Ubuntu and
LTS documented?  Does this mean,
>>>>>>>> > for example, that we will not be able to
use C++17 until 2023 (16.04 LTS
>>>>>>>> > has only GCC 5.3.1)?  That seems a bit
unreasonable.  And there's no
>>>>>>>> > guarantee that 18.04 LTS will even have
GCC 7 or higher either, so it could
>>>>>>>> > be 2025 or 2027.
>>>>>>>> > 
>>>>>>>> > * We've asked people in the past to
build a modern toolchain.  For example,
>>>>>>>> > we did it with C++11 and Ubuntu 12.04 LTS.
Is C++17 compelling enough to
>>>>>>>> > justify this again?
>>>>>>>> > 
>>>>>>>> > * GCC 4.9 probably isn't sufficient to
justify an increase for anyone, as
>>>>>>>> > it lacks two of the more sought-after
features of C++14 (variable templates
>>>>>>>> > and generalized constexpr).  So IMO we
should require a bump to GCC 5 or
>>>>>>>> > higher, or not at all.
>>>>>>>> > 
>>>>>>>> > * Clang 6 supports all of C++20, and it
builds with only C++11, so we
>>>>>>>> > shouldn't have to worry too much about
the problem of needing to "daisy
>>>>>>>> > chain" compilers to finally get the
latest version of LLVM building.  "GCC
>>>>>>>> > 4.8 -> Clang 6 - > Clang ToT"
should hold up through C++1z.
>>>>>>>> > 
>>>>>>>> > * While we obviously can't be tied to
the versioning of every single distro
>>>>>>>> > out there, some are "bigger"
than others.  Which are big enough that
>>>>>>>> > warrant serious consideration?  The ones I
found are (and I did my best to
>>>>>>>> > aggregate all this, but please correct me
if anything is incorrect or
>>>>>>>> > misrepresented):
>>>>>>>> > 
>>>>>>>> > OpenBSD - Ships with GCC 4.2.1 anyway. 
They are already having to
>>>>>>>> > bootstrap something, so the proposal here
does not change anything, because
>>>>>>>> > even current LLVM doesn't compile with
GCC 4.2.1
>>>>>>>> > 
>>>>>>>> > CentOS & RHEL - No version of Distro,
including trunk, has GCC >= 4.8.5
>>>>>>>> > (are there ports?)
>>>>>>>> > 
>>>>>>>> > Debian - Minimum version 9 for GCC >= 5
(are there ports for earlier
>>>>>>>> > releases?)
>>>>>>>> > 
>>>>>>>> > Fedora - Minimum version 24 for GCC >=
5, minimum version 26 for GCC >= 7
>>>>>>>> > 
>>>>>>>> > Ubuntu - Minimum LTS 16.04 for GCC >= 5
>>>>>>>> > 
>>>>>>>> > NetBSD - Version 7 has GCC 4.8.4 by
default, but contains port for 5.3.0
>>>>>>>> > 
>>>>>>>> > FreeBSD - Minimum Version 11 for GCC >=
5
>>>>>>>> > 
>>>>>>>> > So, thoughts?
>>>>>>>> > 
>>>>>>>> > 
>>>>>>>> > [1] - Note that we'd need to wait a
few more revs for MSVC before allowing
>>>>>>>> > C++17, but given that it's becoming
easier and easier to bump the minimum
>>>>>>>> > MSVC version, I'm discounting this as
a factor, as MSVC will not really be
>>>>>>>> > the bottleneck in any real sense.
>>>>>>>> > 
>>>>>>>> > On Tue, Oct 4, 2016 at 2:15 PM Mehdi Amini
<mehdi.amini at apple.com <http://apple.com/>> wrote:
>>>>>>>> > 
>>>>>>>> >> 
>>>>>>>> >> On Oct 4, 2016, at 2:10 PM, Reid
Kleckner <rnk at google.com <http://google.com/>> wrote:
>>>>>>>> >> 
>>>>>>>> >> On Tue, Oct 4, 2016 at 11:58 AM, Mehdi
Amini <mehdi.amini at apple.com <http://apple.com/>>
>>>>>>>> >> wrote:
>>>>>>>> >> 
>>>>>>>> >>> 
>>>>>>>> >>> On Oct 4, 2016, at 8:40 AM, Reid
Kleckner via llvm-dev <
>>>>>>>> >>> llvm-dev at lists.llvm.org
<http://lists.llvm.org/>> wrote:
>>>>>>>> >>> 
>>>>>>>> >>> On Tue, Oct 4, 2016 at 8:29 AM,
Zachary Turner <zturner at google.com <http://google.com/>>
>>>>>>>> >>> wrote:
>>>>>>>> >>>> 
>>>>>>>> >>>> I ask because many of these
LTS distros are notoriously slow at updating
>>>>>>>> >>>> their packages. While some
people may think C++14 doesn't provide enough
>>>>>>>> >>>> bang for the buck to justify
bumping to GCC 4.9, C++17 definitely does. But
>>>>>>>> >>>> at that point we're going
to be talking about GCC 6.1 or 6.2, which is
>>>>>>>> >>>> going to be significantly
harder unless we want to wait 5-7 years, and I
>>>>>>>> >>>> suspect people won't.
>>>>>>>> >>>> 
>>>>>>>> >>> 
>>>>>>>> >>> If by "notoriously slow"
you mean they don't bump their toolchain
>>>>>>>> >>> versions at all, then yeah. We
just wait until the LTS release is at
>>>>>>>> >>> end-of-life before dropping it.
>>>>>>>> >>> 
>>>>>>>> >>> 
>>>>>>>> >>> That’s the first time I read about
this policy: we support every linux
>>>>>>>> >>> LTS distribution till their
end-of-life? Only Ubuntu? Do you have a pointer
>>>>>>>> >>> where it is documented /
discussed?
>>>>>>>> >>> (Note that Ubuntu LTS is 5 years
AFAIK.)
>>>>>>>> >>> 
>>>>>>>> >> 
>>>>>>>> >> Sorry, I didn't mean to refer to
the LTS support lifetime. I just meant we
>>>>>>>> >> support the last LTS until we can
reasonably expect users to have upgraded
>>>>>>>> >> to the new one. If there's an LTS
release every two years, then we want to
>>>>>>>> >> keep supporting them for at least
three years to give people a year to
>>>>>>>> >> upgrade.
>>>>>>>> >> 
>>>>>>>> >> 
>>>>>>>> >> OK, got it.
>>>>>>>> >> 
>>>>>>>> >> Thanks for clarifying!
>>>>>>>> >> 
>>>>>>>> >> Mehdi
>>>>>>>> >> 
>>>>>>>> >> 
>>>>>>>> _______________________________________________
>>>>>>>> LLVM Developers mailing list
>>>>>>>> llvm-dev at lists.llvm.org <mailto:llvm-dev
at lists.llvm.org>
>>>>>>>>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>_______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180511/4bdf006f/attachment-0001.html>

Apparently Analagous Threads

Search for more seemingly similar threads

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

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

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

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

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

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

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

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

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

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

Apparently Analagous Threads