thr3ads.net - llvm dev - [llvm-dev] [RFC] migrating past C++11 [Jan 2019]

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

JF Bastien via llvm-dev

2019-Jan-22 21:44 UTC

[llvm-dev] [RFC] migrating past C++11

Hello fans of the auto keyword!

We now have a policy on how LLVM toolchains get updated
<https://reviews.llvm.org/rL351765>! Let’s put that policy to good use,
and talk about how we’ll move all monorepo projects past C++11.


Previous Discussions
LLVM dev meeting 2018 BoF "Migrating to C++14, and beyond!
<http://llvm.org/devmtg/2018-10/talk-abstracts.html#bof3>"
A Short Policy Proposal Regarding Host Compilers
<http://lists.llvm.org/pipermail/llvm-dev/2018-May/123238.html>
Using C++14 code in LLVM (2018)
<http://lists.llvm.org/pipermail/llvm-dev/2018-May/123182.html>
Using C++14 code in LLVM (2017)
<http://lists.llvm.org/pipermail/llvm-dev/2017-October/118673.html>
Using C++14 code in LLVM (2016)
<http://lists.llvm.org/pipermail/llvm-dev/2016-October/105483.html>
Document and Enforce new Host Compiler Policy <http://llvm.org/D47073>
Require GCC 5.1 and LLVM 3.5 at a minimum <http://llvm.org/D46723>

Migrate to what?

I’m only proposing that we migrate to C++14 for now. If you want to propose
C++17, please do the work required by the policy. In particular, document which
toolchains this would require, and what features you’d unlock. As per policy, I
want to start soft-errors when building LLVM 8, so that LLVM 9 can use more than
C++11.


Timeline

At the LLVM dev meeting BoF, the room already agreed to move past C++11. Late
March 2019 was proposed as a time when we’d start migrating, pending large
contributors’ readiness. I’m sticking to that timeline, we’ll see if everyone is
ready at the end of March. I nonetheless want to get the soft-errors into the
LLVM 8 branch so that we give a sufficient heads-up to developers who only
compile releases.


Upsides

One clear upside of dropping older toolchains: they don’t even support C++11
very well. We have a handful of workarounds left in ADT (particularly around
type traits) and I’d like to get rid of them.

The compiler versions I propose allow us to use all of C++14, which includes:
Binary literals
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf>
decltype(auto), Return type deduction for normal functions
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3638.html>
Initialized/Generalized lambda captures (init-capture)
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3648.html>
Generic (polymorphic) lambda expressions
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3649.html>
Variable templates
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3651.pdf>
Member initializers and aggregates (NSDMI)
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3653.html>
A bunch of new constexpr language and library features
Various other language and library features
See CppReference <https://en.cppreference.com/w/cpp/compiler_support> for
details.

Of these, I think polymorphic lambdas are the big feature. Of course, just like
Almost Always Auto, we should use such things only where it makes sense.


Toolchains

We’re currently mandating:
Clang 3.1 (released 2012/05)
Apple Clang 3.1 (released 2012/05)
GCC 4.8 (released 2013/03)
Visual Studio 2015 (Update 3) (released 2016/06)
I propose instead:
Clang 3.5 (released 2014/07) to get -std=c++14 instead of -std=c++1y
Apple Clang 6.0 (released 2014/07) to match clang 3.5
GCC 5.1 (released 2015/04) because C++14 mostly came to be in GCC 5
Visual Studio 2017 (released 2017/03) so that we get extended constexpr and
NSDMI
Version information from:
Clang http://releases.llvm.org <http://releases.llvm.org/>
Apple clang https://trac.macports.org/wiki/XcodeVersionInfo
<https://trac.macports.org/wiki/XcodeVersionInfo> and
https://en.wikipedia.org/wiki/Xcode#Latest_versions
<https://en.wikipedia.org/wiki/Xcode#Latest_versions>
GCC https://gcc.gnu.org/releases.html <https://gcc.gnu.org/releases.html>
MSVC https://en.wikipedia.org/wiki/Microsoft_Visual_Studio
<https://en.wikipedia.org/wiki/Microsoft_Visual_Studio> and
https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance
<https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance>

My previous attempts pointed out that WebKit / Chromium / Firefox are all past
C++11 (WebKit is moving to C++17
<https://lists.webkit.org/pipermail/webkit-dev/2018-March/029922.html>
(from C++14), Chromium started moving to C++14
<https://groups.google.com/a/chromium.org/d/msg/cxx/ow7hmdDm4yw/eV6KWL2yAQAJ>,
Firefox uses some C++14
<https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code>).
This means that platforms which distribute a modern browser can already
bootstrap a browser. That’s a nice datapoint, but isn’t sufficient for platforms
which compile / use LLVM (especially as a library).

Here’s a table from the LLVM dev meeting BoF detailing version info for distros
that seemed relevant:

Release
Distro
Compiler
C++14 lang
2003-10
RHEL 3
GCC 3.2
❌
2005-02
RHEL 4
GCC 3.4
❌
2007-03
RHEL 5
GCC 4.1
❌
2010-11
RHEL 6
GCC 4.4
❌
2013-05
Debian 7 wheezy
GCC 4.7.2
❌
2013-12
RHEL 7
GCC 4.8
❌
2015-04
Debian 8 jessie
GCC 4.9.2
❌
2015-05
OpenBSD 5.7
LLVM 3.5
✅
2015-10
OpenBSD 5.8
LLVM 3.5
✅
2016-03
OpenBSD 5.9
LLVM 3.5
✅
2016-04
Ubuntu 14.04
GCC 4.8.2
❌
2016-04
Ubuntu 16.04
GCC 5.3.1
✅
2016-09
OpenBSD 6.0
LLVM 3.8
✅
2017-04
OpenBSD 6.1
LLVM 4.0.0
✅
2017-06
Debian 9 stretch
GCC 6.3.0
✅
2017-10
Ubuntu 17.10
GCC 7.2.0
✅
2017-10
OpenBSD 6.2
LLVM 5.0.0
✅
2018-04
Ubuntu 18.04
GCC 7.3.0
✅
2018-04
OpenBSD 6.3
LLVM 5.0.1
✅
2018-10
Ubuntu 18.10
GCC 8.1.0
✅
2018-??
Debian 10 buster
GCC 8.1.0
✅

The data comes from the following sources:
https://en.cppreference.com/w/cpp/compiler_support
<https://en.cppreference.com/w/cpp/compiler_support>
https://packages.ubuntu.com/search?keywords=gcc
<https://packages.ubuntu.com/search?keywords=gcc>
https://packages.debian.org/search?keywords=gcc
<https://packages.debian.org/search?keywords=gcc>
https://access.redhat.com/solutions/19458
<https://access.redhat.com/solutions/19458>
https://www.openbsd.org/63.html <https://www.openbsd.org/63.html>
https://en.wikipedia.org/wiki/Clang <https://en.wikipedia.org/wiki/Clang>
https://releases.llvm.org <https://releases.llvm.org/>
I haven’t documented FreeBSD / NetBSD / Fedora / MacOS / MSVC, and nobody
complained at the BoF. I’d like to understand if we should care about
documenting these: ideally the toolchain update policy would list which
platforms need to be considered and how far back in time is relevant.

Thanks,

JF
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190122/cfd6e67d/attachment.html>

Nathan Froyd via llvm-dev

2019-Jan-22 21:55 UTC

head link

[llvm-dev] [RFC] migrating past C++11

On Tue, Jan 22, 2019 at 4:45 PM JF Bastien via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I propose instead:
>
>    - Clang 3.5 (*released 2014/07*) to get -std=c++14 instead of
>    -std=c++1y
>    - Apple Clang 6.0 (*released 2014/07*) to match clang 3.5
>    - GCC 5.1 (*released 2015/04*) because C++14 mostly came to be in GCC 5
>    - Visual Studio 2017 (*released 2017/03*) so that we get extended
>    constexpr and NSDMI
>
> This is a most excellent proposal.  I know Firefox's C++ page says thatextended constexpr support in GCC 5.0, but my recollection is that the
support is much improved in GCC 6.1+.  GCC 6.x's constexpr support was
certainly the driving motivation for Firefox's requiring GCC 6.1.  You may
want to consider bumping your GCC support level a bit; according to your
table, it leaves Ubuntu 16.04 out in a cold a little bit, but maybe that's
OK?

-Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190122/a12b5e58/attachment.html>

Josh Stone via llvm-dev

2019-Jan-22 22:11 UTC

head link

[llvm-dev] [RFC] migrating past C++11

On 1/22/19 1:44 PM, JF Bastien via llvm-dev wrote:> *Release*
> 	
> *Distro*
> 	
> *Compiler*
> 	
> *C++14 lang*
> *2003-10*
> 	
> RHEL 3
> 	
> GCC 3.2
> 	
> ❌
> *2005-02*
> 	
> RHEL 4
> 	
> GCC 3.4
> 	
> ❌
> *2007-03*
> 	
> RHEL 5
> 	
> GCC 4.1
> 	
> ❌
> *2010-11*
> 	
> RHEL 6
> 	
> GCC 4.4
> 	
> ❌
> *2013-12*
> 	
> RHEL 7
> 	
> GCC 4.8
> 	
> ❌
>For RHEL's sake, note that one can get newer GCC here:

https://developers.redhat.com/products/developertoolset/overview/

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190122/38425990/attachment-0001.html>

Brooks Davis via llvm-dev

2019-Jan-22 22:15 UTC

head link

[llvm-dev] [RFC] migrating past C++11

On Tue, Jan 22, 2019 at 01:44:54PM -0800, JF Bastien via llvm-dev
wrote:> I haven???t documented FreeBSD / NetBSD / Fedora / MacOS / MSVC, and nobody
complained at the BoF. I???d like to understand if we should care about
documenting these: ideally the toolchain update policy would list which
platforms need to be considered and how far back in time is relevant.
For FreeBSD, the relevant issue version included in latest supported
releases on each branch is (since we need to be able to build the HEAD
OS version from at least the previous release.)  That's currently 6.0
for both FreeBSD 11.2 and 12.0.

In the past, we've not done major toolchain upgrades on release
branches, but that changed in FreeBSD 11 and I personally expect use
to keep doing them to at least some extent.  The pain of maintaining
packages on top of clang 3.4 in FreeBSD 10.4 was just too much near its
end of life.

We also support many LLVM version in our ports/package collection.
Currently 3.5, 3.8, 4.0, 5.0, 6.0, 7.0, and an erratically updated
snapshot of the head of the tree.  Since we currently bundle a specific
version into the release branch, these versions don't really enter into
the picture for minimum version and they don't provide a C++ standard
library and depend on the one in the base OS.

Long story short, release branches currently have pretty up to date
clang/llvm/libc++ versions and we're certainly fine with a move to
C++14.  (My guess is that C++17 would be fine as well.)

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190122/23ba4b0f/attachment.sig>

Philip Reames via llvm-dev

2019-Jan-23 01:41 UTC

head link

[llvm-dev] [RFC] migrating past C++11

I have no objection to the end of March timeline for C++14.  This will 
still be a bit of a pain for us, but at the moment, I think we're on 
target for the previously communicated dates.  I'll note that having a 
lot of warning for this (Nov to March) was a key factor in my no 
objection response.  :)

Philip

On 1/22/19 1:44 PM, JF Bastien via llvm-dev wrote:> Hello fans of the auto keyword!
>
> We now have a policy on how LLVM toolchains get updated 
> <https://reviews.llvm.org/rL351765>! Let’s put that policy to good 
> use, and talk about how we’ll move all monorepo projects past C++11.
>
>
> *Previous Discussions*
>
>   * LLVM dev meeting 2018 BoF "Migrating to C++14, and beyond!
>     <http://llvm.org/devmtg/2018-10/talk-abstracts.html#bof3>"
>   * A Short Policy Proposal Regarding Host Compilers
>     <http://lists.llvm.org/pipermail/llvm-dev/2018-May/123238.html>
>   * Using C++14 code in LLVM (2018)
>     <http://lists.llvm.org/pipermail/llvm-dev/2018-May/123182.html>
>   * Using C++14 code in LLVM (2017)
>    
<http://lists.llvm.org/pipermail/llvm-dev/2017-October/118673.html>
>   * Using C++14 code in LLVM (2016)
>    
<http://lists.llvm.org/pipermail/llvm-dev/2016-October/105483.html>
>   * Document and Enforce new Host Compiler Policy
<http://llvm.org/D47073>
>   * Require GCC 5.1 and LLVM 3.5 at a minimum
<http://llvm.org/D46723>
>
> *
> *
> *Migrate to what?*
>
> I’m only proposing that we migrate to C++14 for now. If you want to 
> propose C++17, please do the work required by the policy. In 
> particular, document which toolchains this would require, and what 
> features you’d unlock. As per policy, I want to start soft-errors when 
> building LLVM 8, so that LLVM 9 can use more than C++11.
>
>
> *Timeline*
>
> At the LLVM dev meeting BoF, the room already agreed to move past 
> C++11. Late March 2019 was proposed as a time when we’d start 
> migrating, pending large contributors’ readiness. I’m sticking to that 
> timeline, we’ll see if everyone is ready at the end of March. I 
> nonetheless want to get the soft-errors into the LLVM 8 branch so that 
> we give a sufficient heads-up to developers who only compile releases.
>
>
> *Upsides*
>
> One clear upside of dropping older toolchains: they don’t even support 
> C++11 very well. We have a handful of workarounds left in ADT 
> (particularly around type traits) and I’d like to get rid of them.
>
> The compiler versions I propose allow us to use all of C++14, which 
> includes:
>
>   * Binary literals
>    
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf>
>   * decltype(auto), Return type deduction for normal functions
>    
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3638.html>
>   * Initialized/Generalized lambda captures (init-capture)
>    
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3648.html>
>   * Generic (polymorphic) lambda expressions
>    
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3649.html>
>   * Variable templates
>    
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3651.pdf>
>   * Member initializers and aggregates (NSDMI)
>    
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3653.html>
>   * A bunch of new constexpr language and library features
>   * Various other language and library features
>
> See CppReference 
> <https://en.cppreference.com/w/cpp/compiler_support> for details.
>
> Of these, I think polymorphic lambdas are the big feature. Of course, 
> just like Almost Always Auto, we should use such things only where it 
> makes sense.
>
>
> *Toolchains*
>
> We’re currently mandating:
>
>   * Clang 3.1 (/released 2012/05/)
>   * Apple Clang 3.1 (/released 2012/05/)
>   * GCC 4.8 (/released 2013/03/)
>   * Visual Studio 2015 (Update 3) (/released 2016/06/)
>
> I propose instead:
>
>   * Clang 3.5 (/released 2014/07/) to get -std=c++14 instead of -std=c++1y
>   * Apple Clang 6.0 (/released 2014/07/) to match clang 3.5
>   * GCC 5.1 (/released 2015/04/) because C++14 mostly came to be in GCC 5
>   * Visual Studio 2017 (/released 2017/03/) so that we get extended
>     constexpr and NSDMI
>
> Version information from:
>
>   * Clang http://releases.llvm.org
>   * Apple clang https://trac.macports.org/wiki/XcodeVersionInfo and
>     https://en.wikipedia.org/wiki/Xcode#Latest_versions
>   * GCC https://gcc.gnu.org/releases.html
>   * MSVC https://en.wikipedia.org/wiki/Microsoft_Visual_Studio and
>     https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance
>
>
> My previous attempts pointed out that WebKit / Chromium / Firefox are 
> all past C++11 (WebKit is moving to C++17 
>
<https://lists.webkit.org/pipermail/webkit-dev/2018-March/029922.html> (from
> C++14), Chromium started moving to C++14 
>
<https://groups.google.com/a/chromium.org/d/msg/cxx/ow7hmdDm4yw/eV6KWL2yAQAJ>,
> Firefox uses some C++14 
>
<https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code>).
> This means that platforms which distribute a modern browser can 
> already bootstrap a browser. That’s a nice datapoint, but isn’t 
> sufficient for platforms which compile / use LLVM (especially as a 
> library).
>
> Here’s a table from the LLVM dev meeting BoF detailing version info 
> for distros that seemed relevant:
>
> *Release*
> 	
> *Distro*
> 	
> *Compiler*
> 	
> *C++14 lang*
> *2003-10*
> 	
> RHEL 3
> 	
> GCC 3.2
> 	
> ❌
> *2005-02*
> 	
> RHEL 4
> 	
> GCC 3.4
> 	
> ❌
> *2007-03*
> 	
> RHEL 5
> 	
> GCC 4.1
> 	
> ❌
> *2010-11*
> 	
> RHEL 6
> 	
> GCC 4.4
> 	
> ❌
> *2013-05*
> 	
> Debian 7 wheezy
> 	
> GCC 4.7.2
> 	
> ❌
> *2013-12*
> 	
> RHEL 7
> 	
> GCC 4.8
> 	
> ❌
> *2015-04*
> 	
> Debian 8 jessie
> 	
> GCC 4.9.2
> 	
> ❌
> *2015-05*
> 	
> OpenBSD 5.7
> 	
> LLVM 3.5
> 	
> ✅
> *2015-10*
> 	
> OpenBSD 5.8
> 	
> LLVM 3.5
> 	
> ✅
> *2016-03*
> 	
> OpenBSD 5.9
> 	
> LLVM 3.5
> 	
> ✅
> *2016-04*
> 	
> Ubuntu 14.04
> 	
> GCC 4.8.2
> 	
> ❌
> *2016-04*
> 	
> Ubuntu 16.04
> 	
> GCC 5.3.1
> 	
> ✅
> *2016-09*
> 	
> OpenBSD 6.0
> 	
> LLVM 3.8
> 	
> ✅
> *2017-04*
> 	
> OpenBSD 6.1
> 	
> LLVM 4.0.0
> 	
> ✅
> *2017-06*
> 	
> Debian 9 stretch
> 	
> GCC 6.3.0
> 	
> ✅
> *2017-10*
> 	
> Ubuntu 17.10
> 	
> GCC 7.2.0
> 	
> ✅
> *2017-10*
> 	
> OpenBSD 6.2
> 	
> LLVM 5.0.0
> 	
> ✅
> *2018-04*
> 	
> Ubuntu 18.04
> 	
> GCC 7.3.0
> 	
> ✅
> *2018-04*
> 	
> OpenBSD 6.3
> 	
> LLVM 5.0.1
> 	
> ✅
> *2018-10*
> 	
> Ubuntu 18.10
> 	
> GCC 8.1.0
> 	
> ✅
> *2018-??*
> 	
> Debian 10 buster
> 	
> GCC 8.1.0
> 	
> ✅
>
>
> The data comes from the following sources:
>
>   * https://en.cppreference.com/w/cpp/compiler_support
>   * https://packages.ubuntu.com/search?keywords=gcc
>   * https://packages.debian.org/search?keywords=gcc
>   * https://access.redhat.com/solutions/19458
>   * https://www.openbsd.org/63.html
>   * https://en.wikipedia.org/wiki/Clang
>   * https://releases.llvm.org
>
> I haven’t documented FreeBSD / NetBSD / Fedora / MacOS / MSVC, and 
> nobody complained at the BoF. I’d like to understand if we should care 
> about documenting these: ideally the toolchain update policy would 
> list which platforms need to be considered and how far back in time is 
> relevant.
>
> Thanks,
>
> JF
>
> _______________________________________________
> 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/20190122/9744f0f6/attachment-0001.html>

Serge Guelton via llvm-dev

2019-Jan-23 06:44 UTC

head link

[llvm-dev] [RFC] migrating past C++11

On Tue, Jan 22, 2019 at 01:44:54PM -0800, JF Bastien via llvm-dev
wrote:> I propose instead:
> 
>   • Clang 3.5 (released 2014/07) to get -std=c++14 instead of -std=c++1y
>   • Apple Clang 6.0 (released 2014/07) to match clang 3.5
>   • GCC 5.1 (released 2015/04) because C++14 mostly came to be in GCC 5
>   • Visual Studio 2017 (released 2017/03) so that we get extended constexpr
and
>     NSDMI
Having struggling *a lot* to implement decent is_trivially_copyable<...>
support
in the LLVM codebase for gcc 4.9, I can only second this version bump.

Krzysztof Parzyszek via llvm-dev

2019-Jan-23 15:22 UTC

head link

[llvm-dev] [RFC] migrating past C++11

On 1/22/2019 3:44 PM, JF Bastien via llvm-dev wrote:> One clear upside of dropping older toolchains: they don’t even support 
> C++11 very well.
Do we know that the proposed newer compilers support C++14 very well? 
If we encounter issues with them, how are we going to deal with that?

-Krzysztof

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

James Y Knight via llvm-dev

2019-Jan-23 15:36 UTC

head link

[llvm-dev] [RFC] migrating past C++11

I'd expect that either we'll either workaround the issues (e.g. not
start
using the broken feature), or else propose to require even newer
versions. And as now, discuss the expected tradeoff between new features
and requiring new compiler versions.

On Wed, Jan 23, 2019 at 10:22 AM Krzysztof Parzyszek via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 1/22/2019 3:44 PM, JF Bastien via llvm-dev wrote:
> > One clear upside of dropping older toolchains: they don’t even support
> > C++11 very well.
>
> Do we know that the proposed newer compilers support C++14 very well?
> If we encounter issues with them, how are we going to deal with that?
>
> -Krzysztof
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
> _______________________________________________
> 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/20190123/01da4fc0/attachment.html>

James Y Knight via llvm-dev

2019-Jan-23 19:15 UTC

head link

[llvm-dev] [RFC] migrating past C++11

I think this proposal looks really good -- I'm all in favor of making the
soft-error change immediately for trunk _and_ LLVM 8 branch, and targeting
end of march for the cutover to a hard error and allowing C++14 features.

However...... and I must admit to feeling embarrassed to have to say this,
since Google is probably going to be the very last holdout...but...I'm not
sure Google will actually be able to require C++14 support by the planned
date at end of March. We're very much working on it, but I don't want
everyone to be surprised and upset if, come March 30, we're still not quite
ready to switch over.

So, let's move forward with end-of-march as the current proposal, anyhow,
but I'd just like to ask for forgiveness in advance in case we request a
further delay as that date gets closer. (FTR, I'd expect any future version
increase proposals to see no objections from Google; this is a
one-time-only sort of a problem for us.)


On Tue, Jan 22, 2019 at 4:45 PM JF Bastien via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hello fans of the auto keyword!
>
> We now have a policy on how LLVM toolchains get updated
> <https://reviews.llvm.org/rL351765>! Let’s put that policy to good
use,
> and talk about how we’ll move all monorepo projects past C++11.
>
>
> *Previous Discussions*
>
>    - LLVM dev meeting 2018 BoF "Migrating to C++14, and beyond!
>    <http://llvm.org/devmtg/2018-10/talk-abstracts.html#bof3>"
>    - A Short Policy Proposal Regarding Host Compilers
>    <http://lists.llvm.org/pipermail/llvm-dev/2018-May/123238.html>
>    - Using C++14 code in LLVM (2018)
>    <http://lists.llvm.org/pipermail/llvm-dev/2018-May/123182.html>
>    - Using C++14 code in LLVM (2017)
>   
<http://lists.llvm.org/pipermail/llvm-dev/2017-October/118673.html>
>    - Using C++14 code in LLVM (2016)
>   
<http://lists.llvm.org/pipermail/llvm-dev/2016-October/105483.html>
>    - Document and Enforce new Host Compiler Policy
>    <http://llvm.org/D47073>
>    - Require GCC 5.1 and LLVM 3.5 at a minimum
<http://llvm.org/D46723>
>
>
> *Migrate to what?*
>
> I’m only proposing that we migrate to C++14 for now. If you want to
> propose C++17, please do the work required by the policy. In particular,
> document which toolchains this would require, and what features you’d
> unlock. As per policy, I want to start soft-errors when building LLVM 8, so
> that LLVM 9 can use more than C++11.
>
>
> *Timeline*
>
> At the LLVM dev meeting BoF, the room already agreed to move past C++11.
> Late March 2019 was proposed as a time when we’d start migrating, pending
> large contributors’ readiness. I’m sticking to that timeline, we’ll see if
> everyone is ready at the end of March. I nonetheless want to get the
> soft-errors into the LLVM 8 branch so that we give a sufficient heads-up to
> developers who only compile releases.
>
>
> *Upsides*
>
> One clear upside of dropping older toolchains: they don’t even support
> C++11 very well. We have a handful of workarounds left in ADT (particularly
> around type traits) and I’d like to get rid of them.
>
> The compiler versions I propose allow us to use all of C++14, which
> includes:
>
>    - Binary literals
>   
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf>
>    - decltype(auto), Return type deduction for normal functions
>   
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3638.html>
>    - Initialized/Generalized lambda captures (init-capture)
>   
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3648.html>
>    - Generic (polymorphic) lambda expressions
>   
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3649.html>
>    - Variable templates
>   
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3651.pdf>
>    - Member initializers and aggregates (NSDMI)
>   
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3653.html>
>    - A bunch of new constexpr language and library features
>    - Various other language and library features
>
> See CppReference <https://en.cppreference.com/w/cpp/compiler_support>
for
> details.
>
> Of these, I think polymorphic lambdas are the big feature. Of course, just
> like Almost Always Auto, we should use such things only where it makes
> sense.
>
>
> *Toolchains*
>
> We’re currently mandating:
>
>    - Clang 3.1 (*released 2012/05*)
>    - Apple Clang 3.1 (*released 2012/05*)
>    - GCC 4.8 (*released 2013/03*)
>    - Visual Studio 2015 (Update 3) (*released 2016/06*)
>
> I propose instead:
>
>    - Clang 3.5 (*released 2014/07*) to get -std=c++14 instead of
>    -std=c++1y
>    - Apple Clang 6.0 (*released 2014/07*) to match clang 3.5
>    - GCC 5.1 (*released 2015/04*) because C++14 mostly came to be in GCC 5
>    - Visual Studio 2017 (*released 2017/03*) so that we get extended
>    constexpr and NSDMI
>
> Version information from:
>
>    - Clang http://releases.llvm.org
>    - Apple clang https://trac.macports.org/wiki/XcodeVersionInfo and
>    https://en.wikipedia.org/wiki/Xcode#Latest_versions
>    - GCC https://gcc.gnu.org/releases.html
>    - MSVC https://en.wikipedia.org/wiki/Microsoft_Visual_Studio and
>    https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance
>
>
> My previous attempts pointed out that WebKit / Chromium / Firefox are all
> past C++11 (WebKit is moving to C++17
>
<https://lists.webkit.org/pipermail/webkit-dev/2018-March/029922.html>
(from
> C++14), Chromium started moving to C++14
>
<https://groups.google.com/a/chromium.org/d/msg/cxx/ow7hmdDm4yw/eV6KWL2yAQAJ>,
> Firefox uses some C++14
>
<https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code>).
> This means that platforms which distribute a modern browser can already
> bootstrap a browser. That’s a nice datapoint, but isn’t sufficient for
> platforms which compile / use LLVM (especially as a library).
>
> Here’s a table from the LLVM dev meeting BoF detailing version info for
> distros that seemed relevant:
>
> *Release*
> *Distro*
> *Compiler*
> *C++14 lang*
> *2003-10*
> RHEL 3
> GCC 3.2
> ❌
> *2005-02*
> RHEL 4
> GCC 3.4
> ❌
> *2007-03*
> RHEL 5
> GCC 4.1
> ❌
> *2010-11*
> RHEL 6
> GCC 4.4
> ❌
> *2013-05*
> Debian 7 wheezy
> GCC 4.7.2
> ❌
> *2013-12*
> RHEL 7
> GCC 4.8
> ❌
> *2015-04*
> Debian 8 jessie
> GCC 4.9.2
> ❌
> *2015-05*
> OpenBSD 5.7
> LLVM 3.5
> ✅
> *2015-10*
> OpenBSD 5.8
> LLVM 3.5
> ✅
> *2016-03*
> OpenBSD 5.9
> LLVM 3.5
> ✅
> *2016-04*
> Ubuntu 14.04
> GCC 4.8.2
> ❌
> *2016-04*
> Ubuntu 16.04
> GCC 5.3.1
> ✅
> *2016-09*
> OpenBSD 6.0
> LLVM 3.8
> ✅
> *2017-04*
> OpenBSD 6.1
> LLVM 4.0.0
> ✅
> *2017-06*
> Debian 9 stretch
> GCC 6.3.0
> ✅
> *2017-10*
> Ubuntu 17.10
> GCC 7.2.0
> ✅
> *2017-10*
> OpenBSD 6.2
> LLVM 5.0.0
> ✅
> *2018-04*
> Ubuntu 18.04
> GCC 7.3.0
> ✅
> *2018-04*
> OpenBSD 6.3
> LLVM 5.0.1
> ✅
> *2018-10*
> Ubuntu 18.10
> GCC 8.1.0
> ✅
> *2018-??*
> Debian 10 buster
> GCC 8.1.0
> ✅
>
> The data comes from the following sources:
>
>    - https://en.cppreference.com/w/cpp/compiler_support
>    - https://packages.ubuntu.com/search?keywords=gcc
>    - https://packages.debian.org/search?keywords=gcc
>    - https://access.redhat.com/solutions/19458
>    - https://www.openbsd.org/63.html
>    - https://en.wikipedia.org/wiki/Clang
>    - https://releases.llvm.org
>
> I haven’t documented FreeBSD / NetBSD / Fedora / MacOS / MSVC, and nobody
> complained at the BoF. I’d like to understand if we should care about
> documenting these: ideally the toolchain update policy would list which
> platforms need to be considered and how far back in time is relevant.
>
> Thanks,
>
> JF
> _______________________________________________
> 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/20190123/90107a2b/attachment-0001.html>

JF Bastien via llvm-dev

2019-Jan-23 19:23 UTC

head link

[llvm-dev] [RFC] migrating past C++11

> On Jan 23, 2019, at 11:15 AM, James Y Knight <jyknight at google.com>
wrote:
> 
> I think this proposal looks really good -- I'm all in favor of making
the soft-error change immediately for trunk _and_ LLVM 8 branch, and targeting
end of march for the cutover to a hard error and allowing C++14 features.
Great, I’ll send a PR soon and we can see concrete details there.

> However...... and I must admit to feeling embarrassed to have to say this,
since Google is probably going to be the very last holdout...but...I'm not
sure Google will actually be able to require C++14 support by the planned date
at end of March. We're very much working on it, but I don't want
everyone to be surprised and upset if, come March 30, we're still not quite
ready to switch over.
Thanks for letting us know. I think that’s totally fine: I’d much rather start
the process and soft-error in LLVM 8 now, and see if everyone is ready in March.
Y’all told us at the BoF that end of March wasn’t a sure thing, and from what
I’ve heard you’ve been hard at work so I see no problem waiting to do the actual
move.

> So, let's move forward with end-of-march as the current proposal,
anyhow, but I'd just like to ask for forgiveness in advance in case we
request a further delay as that date gets closer. (FTR, I'd expect any
future version increase proposals to see no objections from Google; this is a
one-time-only sort of a problem for us.
Sgtm

> On Tue, Jan 22, 2019 at 4:45 PM JF Bastien via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> Hello fans of the auto keyword!
> 
> We now have a policy on how LLVM toolchains get updated
<https://reviews.llvm.org/rL351765>! Let’s put that policy to good use,
and talk about how we’ll move all monorepo projects past C++11.
> 
> 
> Previous Discussions
> LLVM dev meeting 2018 BoF "Migrating to C++14, and beyond!
<http://llvm.org/devmtg/2018-10/talk-abstracts.html#bof3>"
> A Short Policy Proposal Regarding Host Compilers
<http://lists.llvm.org/pipermail/llvm-dev/2018-May/123238.html>
> Using C++14 code in LLVM (2018)
<http://lists.llvm.org/pipermail/llvm-dev/2018-May/123182.html>
> Using C++14 code in LLVM (2017)
<http://lists.llvm.org/pipermail/llvm-dev/2017-October/118673.html>
> Using C++14 code in LLVM (2016)
<http://lists.llvm.org/pipermail/llvm-dev/2016-October/105483.html>
> Document and Enforce new Host Compiler Policy
<http://llvm.org/D47073>
> Require GCC 5.1 and LLVM 3.5 at a minimum <http://llvm.org/D46723>
> 
> Migrate to what?
> 
> I’m only proposing that we migrate to C++14 for now. If you want to propose
C++17, please do the work required by the policy. In particular, document which
toolchains this would require, and what features you’d unlock. As per policy, I
want to start soft-errors when building LLVM 8, so that LLVM 9 can use more than
C++11.
> 
> 
> Timeline
> 
> At the LLVM dev meeting BoF, the room already agreed to move past C++11.
Late March 2019 was proposed as a time when we’d start migrating, pending large
contributors’ readiness. I’m sticking to that timeline, we’ll see if everyone is
ready at the end of March. I nonetheless want to get the soft-errors into the
LLVM 8 branch so that we give a sufficient heads-up to developers who only
compile releases.
> 
> 
> Upsides
> 
> One clear upside of dropping older toolchains: they don’t even support
C++11 very well. We have a handful of workarounds left in ADT (particularly
around type traits) and I’d like to get rid of them.
> 
> The compiler versions I propose allow us to use all of C++14, which
includes:
> Binary literals
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf>
> decltype(auto), Return type deduction for normal functions
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3638.html>
> Initialized/Generalized lambda captures (init-capture)
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3648.html>
> Generic (polymorphic) lambda expressions
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3649.html>
> Variable templates
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3651.pdf>
> Member initializers and aggregates (NSDMI)
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3653.html>
> A bunch of new constexpr language and library features
> Various other language and library features
> See CppReference <https://en.cppreference.com/w/cpp/compiler_support>
for details.
> 
> Of these, I think polymorphic lambdas are the big feature. Of course, just
like Almost Always Auto, we should use such things only where it makes sense.
> 
> 
> Toolchains
> 
> We’re currently mandating:
> Clang 3.1 (released 2012/05)
> Apple Clang 3.1 (released 2012/05)
> GCC 4.8 (released 2013/03)
> Visual Studio 2015 (Update 3) (released 2016/06)
> I propose instead:
> Clang 3.5 (released 2014/07) to get -std=c++14 instead of -std=c++1y
> Apple Clang 6.0 (released 2014/07) to match clang 3.5
> GCC 5.1 (released 2015/04) because C++14 mostly came to be in GCC 5
> Visual Studio 2017 (released 2017/03) so that we get extended constexpr and
NSDMI
> Version information from:
> Clang http://releases.llvm.org <http://releases.llvm.org/>
> Apple clang https://trac.macports.org/wiki/XcodeVersionInfo
<https://trac.macports.org/wiki/XcodeVersionInfo> and
https://en.wikipedia.org/wiki/Xcode#Latest_versions
<https://en.wikipedia.org/wiki/Xcode#Latest_versions>
> GCC https://gcc.gnu.org/releases.html
<https://gcc.gnu.org/releases.html>
> MSVC https://en.wikipedia.org/wiki/Microsoft_Visual_Studio
<https://en.wikipedia.org/wiki/Microsoft_Visual_Studio> and
https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance
<https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance>
> 
> My previous attempts pointed out that WebKit / Chromium / Firefox are all
past C++11 (WebKit is moving to C++17
<https://lists.webkit.org/pipermail/webkit-dev/2018-March/029922.html>
(from C++14), Chromium started moving to C++14
<https://groups.google.com/a/chromium.org/d/msg/cxx/ow7hmdDm4yw/eV6KWL2yAQAJ>,
Firefox uses some C++14
<https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code>).
This means that platforms which distribute a modern browser can already
bootstrap a browser. That’s a nice datapoint, but isn’t sufficient for platforms
which compile / use LLVM (especially as a library).
> 
> Here’s a table from the LLVM dev meeting BoF detailing version info for
distros that seemed relevant:
> 
> Release
> Distro
> Compiler
> C++14 lang
> 2003-10
> RHEL 3
> GCC 3.2
> ❌
> 2005-02
> RHEL 4
> GCC 3.4
> ❌
> 2007-03
> RHEL 5
> GCC 4.1
> ❌
> 2010-11
> RHEL 6
> GCC 4.4
> ❌
> 2013-05
> Debian 7 wheezy
> GCC 4.7.2
> ❌
> 2013-12
> RHEL 7
> GCC 4.8
> ❌
> 2015-04
> Debian 8 jessie
> GCC 4.9.2
> ❌
> 2015-05
> OpenBSD 5.7
> LLVM 3.5
> ✅
> 2015-10
> OpenBSD 5.8
> LLVM 3.5
> ✅
> 2016-03
> OpenBSD 5.9
> LLVM 3.5
> ✅
> 2016-04
> Ubuntu 14.04
> GCC 4.8.2
> ❌
> 2016-04
> Ubuntu 16.04
> GCC 5.3.1
> ✅
> 2016-09
> OpenBSD 6.0
> LLVM 3.8
> ✅
> 2017-04
> OpenBSD 6.1
> LLVM 4.0.0
> ✅
> 2017-06
> Debian 9 stretch
> GCC 6.3.0
> ✅
> 2017-10
> Ubuntu 17.10
> GCC 7.2.0
> ✅
> 2017-10
> OpenBSD 6.2
> LLVM 5.0.0
> ✅
> 2018-04
> Ubuntu 18.04
> GCC 7.3.0
> ✅
> 2018-04
> OpenBSD 6.3
> LLVM 5.0.1
> ✅
> 2018-10
> Ubuntu 18.10
> GCC 8.1.0
> ✅
> 2018-??
> Debian 10 buster
> GCC 8.1.0
> ✅
> 
> The data comes from the following sources:
> https://en.cppreference.com/w/cpp/compiler_support
<https://en.cppreference.com/w/cpp/compiler_support>
> https://packages.ubuntu.com/search?keywords=gcc
<https://packages.ubuntu.com/search?keywords=gcc>
> https://packages.debian.org/search?keywords=gcc
<https://packages.debian.org/search?keywords=gcc>
> https://access.redhat.com/solutions/19458
<https://access.redhat.com/solutions/19458>
> https://www.openbsd.org/63.html <https://www.openbsd.org/63.html>
> https://en.wikipedia.org/wiki/Clang
<https://en.wikipedia.org/wiki/Clang>
> https://releases.llvm.org <https://releases.llvm.org/>
> I haven’t documented FreeBSD / NetBSD / Fedora / MacOS / MSVC, and nobody
complained at the BoF. I’d like to understand if we should care about
documenting these: ideally the toolchain update policy would list which
platforms need to be considered and how far back in time is relevant.
> 
> Thanks,
> 
> JF
> _______________________________________________
> 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/20190123/18e39691/attachment-0001.html>

Stephen Kelly via llvm-dev

2019-Jan-23 20:55 UTC

head link

[llvm-dev] [RFC] migrating past C++11

On 22/01/2019 21:44, JF Bastien via llvm-dev wrote:> The compiler versions I propose allow us to use all of C++14, which 
> includes:
> 
>   * Binary literals
>    
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf>
>   * decltype(auto), Return type deduction for normal functions
>    
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3638.html>
>   * Initialized/Generalized lambda captures (init-capture)
>    
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3648.html>
>   * Generic (polymorphic) lambda expressions
>    
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3649.html>
>   * Variable templates
>    
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3651.pdf>
>   * Member initializers and aggregates (NSDMI)
>    
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3653.html>
>   * A bunch of new constexpr language and library features
>   * Various other language and library features
> 
> See CppReference 
> <https://en.cppreference.com/w/cpp/compiler_support> for details.
> 
> Of these, I think polymorphic lambdas are the big feature. Of course, 
> just like Almost Always Auto, we should use such things only where it 
> makes sense.
Note that when we discussed moderate use of `auto` recently, there was 
no consensus that auto-in-lambdas (ie polymorphic lambdas) should be 
permitted. It's kind of strange to see it hailed as a 'big feature'
if
consensus is not that it should be permitted.

Is there a need for more guidelines about this or any other of these 
newly-unlocked features?

Thanks,

Stephen.

Hubert Tong via llvm-dev

2019-Jan-25 04:47 UTC

head link

[llvm-dev] [RFC] migrating past C++11

I may have missed it, but I don't see mentions of the minimum C++ library
implementation levels (in case Clang is used with an older libstdc++).

-- HT

On Tue, Jan 22, 2019, 4:45 PM JF Bastien via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hello fans of the auto keyword!
>
> We now have a policy on how LLVM toolchains get updated
> <https://reviews.llvm.org/rL351765>! Let’s put that policy to good
use,
> and talk about how we’ll move all monorepo projects past C++11.
>
>
> *Previous Discussions*
>
>    - LLVM dev meeting 2018 BoF "Migrating to C++14, and beyond!
>    <http://llvm.org/devmtg/2018-10/talk-abstracts.html#bof3>"
>    - A Short Policy Proposal Regarding Host Compilers
>    <http://lists.llvm.org/pipermail/llvm-dev/2018-May/123238.html>
>    - Using C++14 code in LLVM (2018)
>    <http://lists.llvm.org/pipermail/llvm-dev/2018-May/123182.html>
>    - Using C++14 code in LLVM (2017)
>   
<http://lists.llvm.org/pipermail/llvm-dev/2017-October/118673.html>
>    - Using C++14 code in LLVM (2016)
>   
<http://lists.llvm.org/pipermail/llvm-dev/2016-October/105483.html>
>    - Document and Enforce new Host Compiler Policy
>    <http://llvm.org/D47073>
>    - Require GCC 5.1 and LLVM 3.5 at a minimum
<http://llvm.org/D46723>
>
>
> *Migrate to what?*
>
> I’m only proposing that we migrate to C++14 for now. If you want to
> propose C++17, please do the work required by the policy. In particular,
> document which toolchains this would require, and what features you’d
> unlock. As per policy, I want to start soft-errors when building LLVM 8, so
> that LLVM 9 can use more than C++11.
>
>
> *Timeline*
>
> At the LLVM dev meeting BoF, the room already agreed to move past C++11.
> Late March 2019 was proposed as a time when we’d start migrating, pending
> large contributors’ readiness. I’m sticking to that timeline, we’ll see if
> everyone is ready at the end of March. I nonetheless want to get the
> soft-errors into the LLVM 8 branch so that we give a sufficient heads-up to
> developers who only compile releases.
>
>
> *Upsides*
>
> One clear upside of dropping older toolchains: they don’t even support
> C++11 very well. We have a handful of workarounds left in ADT (particularly
> around type traits) and I’d like to get rid of them.
>
> The compiler versions I propose allow us to use all of C++14, which
> includes:
>
>    - Binary literals
>   
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf>
>    - decltype(auto), Return type deduction for normal functions
>   
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3638.html>
>    - Initialized/Generalized lambda captures (init-capture)
>   
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3648.html>
>    - Generic (polymorphic) lambda expressions
>   
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3649.html>
>    - Variable templates
>   
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3651.pdf>
>    - Member initializers and aggregates (NSDMI)
>   
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3653.html>
>    - A bunch of new constexpr language and library features
>    - Various other language and library features
>
> See CppReference <https://en.cppreference.com/w/cpp/compiler_support>
for
> details.
>
> Of these, I think polymorphic lambdas are the big feature. Of course, just
> like Almost Always Auto, we should use such things only where it makes
> sense.
>
>
> *Toolchains*
>
> We’re currently mandating:
>
>    - Clang 3.1 (*released 2012/05*)
>    - Apple Clang 3.1 (*released 2012/05*)
>    - GCC 4.8 (*released 2013/03*)
>    - Visual Studio 2015 (Update 3) (*released 2016/06*)
>
> I propose instead:
>
>    - Clang 3.5 (*released 2014/07*) to get -std=c++14 instead of
>    -std=c++1y
>    - Apple Clang 6.0 (*released 2014/07*) to match clang 3.5
>    - GCC 5.1 (*released 2015/04*) because C++14 mostly came to be in GCC 5
>    - Visual Studio 2017 (*released 2017/03*) so that we get extended
>    constexpr and NSDMI
>
> Version information from:
>
>    - Clang http://releases.llvm.org
>    - Apple clang https://trac.macports.org/wiki/XcodeVersionInfo and
>    https://en.wikipedia.org/wiki/Xcode#Latest_versions
>    - GCC https://gcc.gnu.org/releases.html
>    - MSVC https://en.wikipedia.org/wiki/Microsoft_Visual_Studio and
>    https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance
>
>
> My previous attempts pointed out that WebKit / Chromium / Firefox are all
> past C++11 (WebKit is moving to C++17
>
<https://lists.webkit.org/pipermail/webkit-dev/2018-March/029922.html>
(from
> C++14), Chromium started moving to C++14
>
<https://groups.google.com/a/chromium.org/d/msg/cxx/ow7hmdDm4yw/eV6KWL2yAQAJ>,
> Firefox uses some C++14
>
<https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code>).
> This means that platforms which distribute a modern browser can already
> bootstrap a browser. That’s a nice datapoint, but isn’t sufficient for
> platforms which compile / use LLVM (especially as a library).
>
> Here’s a table from the LLVM dev meeting BoF detailing version info for
> distros that seemed relevant:
>
> *Release*
> *Distro*
> *Compiler*
> *C++14 lang*
> *2003-10*
> RHEL 3
> GCC 3.2
> ❌
> *2005-02*
> RHEL 4
> GCC 3.4
> ❌
> *2007-03*
> RHEL 5
> GCC 4.1
> ❌
> *2010-11*
> RHEL 6
> GCC 4.4
> ❌
> *2013-05*
> Debian 7 wheezy
> GCC 4.7.2
> ❌
> *2013-12*
> RHEL 7
> GCC 4.8
> ❌
> *2015-04*
> Debian 8 jessie
> GCC 4.9.2
> ❌
> *2015-05*
> OpenBSD 5.7
> LLVM 3.5
> ✅
> *2015-10*
> OpenBSD 5.8
> LLVM 3.5
> ✅
> *2016-03*
> OpenBSD 5.9
> LLVM 3.5
> ✅
> *2016-04*
> Ubuntu 14.04
> GCC 4.8.2
> ❌
> *2016-04*
> Ubuntu 16.04
> GCC 5.3.1
> ✅
> *2016-09*
> OpenBSD 6.0
> LLVM 3.8
> ✅
> *2017-04*
> OpenBSD 6.1
> LLVM 4.0.0
> ✅
> *2017-06*
> Debian 9 stretch
> GCC 6.3.0
> ✅
> *2017-10*
> Ubuntu 17.10
> GCC 7.2.0
> ✅
> *2017-10*
> OpenBSD 6.2
> LLVM 5.0.0
> ✅
> *2018-04*
> Ubuntu 18.04
> GCC 7.3.0
> ✅
> *2018-04*
> OpenBSD 6.3
> LLVM 5.0.1
> ✅
> *2018-10*
> Ubuntu 18.10
> GCC 8.1.0
> ✅
> *2018-??*
> Debian 10 buster
> GCC 8.1.0
> ✅
>
> The data comes from the following sources:
>
>    - https://en.cppreference.com/w/cpp/compiler_support
>    - https://packages.ubuntu.com/search?keywords=gcc
>    - https://packages.debian.org/search?keywords=gcc
>    - https://access.redhat.com/solutions/19458
>    - https://www.openbsd.org/63.html
>    - https://en.wikipedia.org/wiki/Clang
>    - https://releases.llvm.org
>
> I haven’t documented FreeBSD / NetBSD / Fedora / MacOS / MSVC, and nobody
> complained at the BoF. I’d like to understand if we should care about
> documenting these: ideally the toolchain update policy would list which
> platforms need to be considered and how far back in time is relevant.
>
> Thanks,
>
> JF
> _______________________________________________
> 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/20190124/8f65768e/attachment-0001.html>

JF Bastien via llvm-dev

2019-Jan-25 04:49 UTC

head link

[llvm-dev] [RFC] migrating past C++11

> On Jan 24, 2019, at 8:47 PM, Hubert Tong <hubert.reinterpretcast at
gmail.com> wrote:
> 
> I may have missed it, but I don't see mentions of the minimum C++
library implementation levels (in case Clang is used with an older libstdc++).
libstdc++ is tied to a GCC version, so the documentation we have today
<https://llvm.org/docs/GettingStarted.html> is already sufficient.

> -- HT
> 
> On Tue, Jan 22, 2019, 4:45 PM JF Bastien via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> Hello fans of the auto keyword!
> 
> We now have a policy on how LLVM toolchains get updated
<https://reviews.llvm.org/rL351765>! Let’s put that policy to good use,
and talk about how we’ll move all monorepo projects past C++11.
> 
> 
> Previous Discussions
> LLVM dev meeting 2018 BoF "Migrating to C++14, and beyond!
<http://llvm.org/devmtg/2018-10/talk-abstracts.html#bof3>"
> A Short Policy Proposal Regarding Host Compilers
<http://lists.llvm.org/pipermail/llvm-dev/2018-May/123238.html>
> Using C++14 code in LLVM (2018)
<http://lists.llvm.org/pipermail/llvm-dev/2018-May/123182.html>
> Using C++14 code in LLVM (2017)
<http://lists.llvm.org/pipermail/llvm-dev/2017-October/118673.html>
> Using C++14 code in LLVM (2016)
<http://lists.llvm.org/pipermail/llvm-dev/2016-October/105483.html>
> Document and Enforce new Host Compiler Policy
<http://llvm.org/D47073>
> Require GCC 5.1 and LLVM 3.5 at a minimum <http://llvm.org/D46723>
> 
> Migrate to what?
> 
> I’m only proposing that we migrate to C++14 for now. If you want to propose
C++17, please do the work required by the policy. In particular, document which
toolchains this would require, and what features you’d unlock. As per policy, I
want to start soft-errors when building LLVM 8, so that LLVM 9 can use more than
C++11.
> 
> 
> Timeline
> 
> At the LLVM dev meeting BoF, the room already agreed to move past C++11.
Late March 2019 was proposed as a time when we’d start migrating, pending large
contributors’ readiness. I’m sticking to that timeline, we’ll see if everyone is
ready at the end of March. I nonetheless want to get the soft-errors into the
LLVM 8 branch so that we give a sufficient heads-up to developers who only
compile releases.
> 
> 
> Upsides
> 
> One clear upside of dropping older toolchains: they don’t even support
C++11 very well. We have a handful of workarounds left in ADT (particularly
around type traits) and I’d like to get rid of them.
> 
> The compiler versions I propose allow us to use all of C++14, which
includes:
> Binary literals
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf>
> decltype(auto), Return type deduction for normal functions
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3638.html>
> Initialized/Generalized lambda captures (init-capture)
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3648.html>
> Generic (polymorphic) lambda expressions
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3649.html>
> Variable templates
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3651.pdf>
> Member initializers and aggregates (NSDMI)
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3653.html>
> A bunch of new constexpr language and library features
> Various other language and library features
> See CppReference <https://en.cppreference.com/w/cpp/compiler_support>
for details.
> 
> Of these, I think polymorphic lambdas are the big feature. Of course, just
like Almost Always Auto, we should use such things only where it makes sense.
> 
> 
> Toolchains
> 
> We’re currently mandating:
> Clang 3.1 (released 2012/05)
> Apple Clang 3.1 (released 2012/05)
> GCC 4.8 (released 2013/03)
> Visual Studio 2015 (Update 3) (released 2016/06)
> I propose instead:
> Clang 3.5 (released 2014/07) to get -std=c++14 instead of -std=c++1y
> Apple Clang 6.0 (released 2014/07) to match clang 3.5
> GCC 5.1 (released 2015/04) because C++14 mostly came to be in GCC 5
> Visual Studio 2017 (released 2017/03) so that we get extended constexpr and
NSDMI
> Version information from:
> Clang http://releases.llvm.org <http://releases.llvm.org/>
> Apple clang https://trac.macports.org/wiki/XcodeVersionInfo
<https://trac.macports.org/wiki/XcodeVersionInfo> and
https://en.wikipedia.org/wiki/Xcode#Latest_versions
<https://en.wikipedia.org/wiki/Xcode#Latest_versions>
> GCC https://gcc.gnu.org/releases.html
<https://gcc.gnu.org/releases.html>
> MSVC https://en.wikipedia.org/wiki/Microsoft_Visual_Studio
<https://en.wikipedia.org/wiki/Microsoft_Visual_Studio> and
https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance
<https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance>
> 
> My previous attempts pointed out that WebKit / Chromium / Firefox are all
past C++11 (WebKit is moving to C++17
<https://lists.webkit.org/pipermail/webkit-dev/2018-March/029922.html>
(from C++14), Chromium started moving to C++14
<https://groups.google.com/a/chromium.org/d/msg/cxx/ow7hmdDm4yw/eV6KWL2yAQAJ>,
Firefox uses some C++14
<https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code>).
This means that platforms which distribute a modern browser can already
bootstrap a browser. That’s a nice datapoint, but isn’t sufficient for platforms
which compile / use LLVM (especially as a library).
> 
> Here’s a table from the LLVM dev meeting BoF detailing version info for
distros that seemed relevant:
> 
> Release
> Distro
> Compiler
> C++14 lang
> 2003-10
> RHEL 3
> GCC 3.2
> ❌
> 2005-02
> RHEL 4
> GCC 3.4
> ❌
> 2007-03
> RHEL 5
> GCC 4.1
> ❌
> 2010-11
> RHEL 6
> GCC 4.4
> ❌
> 2013-05
> Debian 7 wheezy
> GCC 4.7.2
> ❌
> 2013-12
> RHEL 7
> GCC 4.8
> ❌
> 2015-04
> Debian 8 jessie
> GCC 4.9.2
> ❌
> 2015-05
> OpenBSD 5.7
> LLVM 3.5
> ✅
> 2015-10
> OpenBSD 5.8
> LLVM 3.5
> ✅
> 2016-03
> OpenBSD 5.9
> LLVM 3.5
> ✅
> 2016-04
> Ubuntu 14.04
> GCC 4.8.2
> ❌
> 2016-04
> Ubuntu 16.04
> GCC 5.3.1
> ✅
> 2016-09
> OpenBSD 6.0
> LLVM 3.8
> ✅
> 2017-04
> OpenBSD 6.1
> LLVM 4.0.0
> ✅
> 2017-06
> Debian 9 stretch
> GCC 6.3.0
> ✅
> 2017-10
> Ubuntu 17.10
> GCC 7.2.0
> ✅
> 2017-10
> OpenBSD 6.2
> LLVM 5.0.0
> ✅
> 2018-04
> Ubuntu 18.04
> GCC 7.3.0
> ✅
> 2018-04
> OpenBSD 6.3
> LLVM 5.0.1
> ✅
> 2018-10
> Ubuntu 18.10
> GCC 8.1.0
> ✅
> 2018-??
> Debian 10 buster
> GCC 8.1.0
> ✅
> 
> The data comes from the following sources:
> https://en.cppreference.com/w/cpp/compiler_support
<https://en.cppreference.com/w/cpp/compiler_support>
> https://packages.ubuntu.com/search?keywords=gcc
<https://packages.ubuntu.com/search?keywords=gcc>
> https://packages.debian.org/search?keywords=gcc
<https://packages.debian.org/search?keywords=gcc>
> https://access.redhat.com/solutions/19458
<https://access.redhat.com/solutions/19458>
> https://www.openbsd.org/63.html <https://www.openbsd.org/63.html>
> https://en.wikipedia.org/wiki/Clang
<https://en.wikipedia.org/wiki/Clang>
> https://releases.llvm.org <https://releases.llvm.org/>
> I haven’t documented FreeBSD / NetBSD / Fedora / MacOS / MSVC, and nobody
complained at the BoF. I’d like to understand if we should care about
documenting these: ideally the toolchain update policy would list which
platforms need to be considered and how far back in time is relevant.
> 
> Thanks,
> 
> JF
> _______________________________________________
> 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/20190124/99386f05/attachment.html>

JF Bastien via llvm-dev

2019-Jan-25 23:56 UTC

head link

[llvm-dev] [RFC] migrating past C++11

The discussion seems to have died down and gotten good consensus. I’ve therefore
create a patch which applies the proposed soft-errors:
https://reviews.llvm.org/D57264 <https://reviews.llvm.org/D57264>

We’ll only migrate to hard-error (and start using new features) when we get
consensus to do so, at the earliest end of March 2019. The patch will allow us
to start warning developers, especially those who only compile branches (in this
case, LLVM 8).

> On Jan 22, 2019, at 1:44 PM, JF Bastien via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Hello fans of the auto keyword!
> 
> We now have a policy on how LLVM toolchains get updated
<https://reviews.llvm.org/rL351765>! Let’s put that policy to good use,
and talk about how we’ll move all monorepo projects past C++11.
> 
> 
> Previous Discussions
> LLVM dev meeting 2018 BoF "Migrating to C++14, and beyond!
<http://llvm.org/devmtg/2018-10/talk-abstracts.html#bof3>"
> A Short Policy Proposal Regarding Host Compilers
<http://lists.llvm.org/pipermail/llvm-dev/2018-May/123238.html>
> Using C++14 code in LLVM (2018)
<http://lists.llvm.org/pipermail/llvm-dev/2018-May/123182.html>
> Using C++14 code in LLVM (2017)
<http://lists.llvm.org/pipermail/llvm-dev/2017-October/118673.html>
> Using C++14 code in LLVM (2016)
<http://lists.llvm.org/pipermail/llvm-dev/2016-October/105483.html>
> Document and Enforce new Host Compiler Policy
<http://llvm.org/D47073>
> Require GCC 5.1 and LLVM 3.5 at a minimum <http://llvm.org/D46723>
> 
> Migrate to what?
> 
> I’m only proposing that we migrate to C++14 for now. If you want to propose
C++17, please do the work required by the policy. In particular, document which
toolchains this would require, and what features you’d unlock. As per policy, I
want to start soft-errors when building LLVM 8, so that LLVM 9 can use more than
C++11.
> 
> 
> Timeline
> 
> At the LLVM dev meeting BoF, the room already agreed to move past C++11.
Late March 2019 was proposed as a time when we’d start migrating, pending large
contributors’ readiness. I’m sticking to that timeline, we’ll see if everyone is
ready at the end of March. I nonetheless want to get the soft-errors into the
LLVM 8 branch so that we give a sufficient heads-up to developers who only
compile releases.
> 
> 
> Upsides
> 
> One clear upside of dropping older toolchains: they don’t even support
C++11 very well. We have a handful of workarounds left in ADT (particularly
around type traits) and I’d like to get rid of them.
> 
> The compiler versions I propose allow us to use all of C++14, which
includes:
> Binary literals
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf>
> decltype(auto), Return type deduction for normal functions
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3638.html>
> Initialized/Generalized lambda captures (init-capture)
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3648.html>
> Generic (polymorphic) lambda expressions
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3649.html>
> Variable templates
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3651.pdf>
> Member initializers and aggregates (NSDMI)
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3653.html>
> A bunch of new constexpr language and library features
> Various other language and library features
> See CppReference <https://en.cppreference.com/w/cpp/compiler_support>
for details.
> 
> Of these, I think polymorphic lambdas are the big feature. Of course, just
like Almost Always Auto, we should use such things only where it makes sense.
> 
> 
> Toolchains
> 
> We’re currently mandating:
> Clang 3.1 (released 2012/05)
> Apple Clang 3.1 (released 2012/05)
> GCC 4.8 (released 2013/03)
> Visual Studio 2015 (Update 3) (released 2016/06)
> I propose instead:
> Clang 3.5 (released 2014/07) to get -std=c++14 instead of -std=c++1y
> Apple Clang 6.0 (released 2014/07) to match clang 3.5
> GCC 5.1 (released 2015/04) because C++14 mostly came to be in GCC 5
> Visual Studio 2017 (released 2017/03) so that we get extended constexpr and
NSDMI
> Version information from:
> Clang http://releases.llvm.org <http://releases.llvm.org/>
> Apple clang https://trac.macports.org/wiki/XcodeVersionInfo
<https://trac.macports.org/wiki/XcodeVersionInfo> and
https://en.wikipedia.org/wiki/Xcode#Latest_versions
<https://en.wikipedia.org/wiki/Xcode#Latest_versions>
> GCC https://gcc.gnu.org/releases.html
<https://gcc.gnu.org/releases.html>
> MSVC https://en.wikipedia.org/wiki/Microsoft_Visual_Studio
<https://en.wikipedia.org/wiki/Microsoft_Visual_Studio> and
https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance
<https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance>
> 
> My previous attempts pointed out that WebKit / Chromium / Firefox are all
past C++11 (WebKit is moving to C++17
<https://lists.webkit.org/pipermail/webkit-dev/2018-March/029922.html>
(from C++14), Chromium started moving to C++14
<https://groups.google.com/a/chromium.org/d/msg/cxx/ow7hmdDm4yw/eV6KWL2yAQAJ>,
Firefox uses some C++14
<https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code>).
This means that platforms which distribute a modern browser can already
bootstrap a browser. That’s a nice datapoint, but isn’t sufficient for platforms
which compile / use LLVM (especially as a library).
> 
> Here’s a table from the LLVM dev meeting BoF detailing version info for
distros that seemed relevant:
> 
> Release
> Distro
> Compiler
> C++14 lang
> 2003-10
> RHEL 3
> GCC 3.2
> ❌
> 2005-02
> RHEL 4
> GCC 3.4
> ❌
> 2007-03
> RHEL 5
> GCC 4.1
> ❌
> 2010-11
> RHEL 6
> GCC 4.4
> ❌
> 2013-05
> Debian 7 wheezy
> GCC 4.7.2
> ❌
> 2013-12
> RHEL 7
> GCC 4.8
> ❌
> 2015-04
> Debian 8 jessie
> GCC 4.9.2
> ❌
> 2015-05
> OpenBSD 5.7
> LLVM 3.5
> ✅
> 2015-10
> OpenBSD 5.8
> LLVM 3.5
> ✅
> 2016-03
> OpenBSD 5.9
> LLVM 3.5
> ✅
> 2016-04
> Ubuntu 14.04
> GCC 4.8.2
> ❌
> 2016-04
> Ubuntu 16.04
> GCC 5.3.1
> ✅
> 2016-09
> OpenBSD 6.0
> LLVM 3.8
> ✅
> 2017-04
> OpenBSD 6.1
> LLVM 4.0.0
> ✅
> 2017-06
> Debian 9 stretch
> GCC 6.3.0
> ✅
> 2017-10
> Ubuntu 17.10
> GCC 7.2.0
> ✅
> 2017-10
> OpenBSD 6.2
> LLVM 5.0.0
> ✅
> 2018-04
> Ubuntu 18.04
> GCC 7.3.0
> ✅
> 2018-04
> OpenBSD 6.3
> LLVM 5.0.1
> ✅
> 2018-10
> Ubuntu 18.10
> GCC 8.1.0
> ✅
> 2018-??
> Debian 10 buster
> GCC 8.1.0
> ✅
> 
> The data comes from the following sources:
> https://en.cppreference.com/w/cpp/compiler_support
<https://en.cppreference.com/w/cpp/compiler_support>
> https://packages.ubuntu.com/search?keywords=gcc
<https://packages.ubuntu.com/search?keywords=gcc>
> https://packages.debian.org/search?keywords=gcc
<https://packages.debian.org/search?keywords=gcc>
> https://access.redhat.com/solutions/19458
<https://access.redhat.com/solutions/19458>
> https://www.openbsd.org/63.html <https://www.openbsd.org/63.html>
> https://en.wikipedia.org/wiki/Clang
<https://en.wikipedia.org/wiki/Clang>
> https://releases.llvm.org <https://releases.llvm.org/>
> I haven’t documented FreeBSD / NetBSD / Fedora / MacOS / MSVC, and nobody
complained at the BoF. I’d like to understand if we should care about
documenting these: ideally the toolchain update policy would list which
platforms need to be considered and how far back in time is relevant.
> 
> Thanks,
> 
> JF
> _______________________________________________
> 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/20190125/1bb0613f/attachment.html>

Chandler Carruth via llvm-dev

2019-Jan-26 01:47 UTC

head link

[llvm-dev] [RFC] migrating past C++11

+1, thanks again for driving this.

On Fri, Jan 25, 2019 at 3:57 PM JF Bastien via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> The discussion seems to have died down and gotten good consensus. I’ve
> therefore create a patch which applies the proposed soft-errors:
>
> https://reviews.llvm.org/D57264
>
>
> We’ll only migrate to hard-error (and start using new features) when we
> get consensus to do so, at the earliest end of March 2019. The patch will
> allow us to start warning developers, especially those who only compile
> branches (in this case, LLVM 8).
>
>
> On Jan 22, 2019, at 1:44 PM, JF Bastien via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hello fans of the auto keyword!
>
> We now have a policy on how LLVM toolchains get updated
> <https://reviews.llvm.org/rL351765>! Let’s put that policy to good
use,
> and talk about how we’ll move all monorepo projects past C++11.
>
>
> *Previous Discussions*
>
>    - LLVM dev meeting 2018 BoF "Migrating to C++14, and beyond!
>    <http://llvm.org/devmtg/2018-10/talk-abstracts.html#bof3>"
>    - A Short Policy Proposal Regarding Host Compilers
>    <http://lists.llvm.org/pipermail/llvm-dev/2018-May/123238.html>
>    - Using C++14 code in LLVM (2018)
>    <http://lists.llvm.org/pipermail/llvm-dev/2018-May/123182.html>
>    - Using C++14 code in LLVM (2017)
>   
<http://lists.llvm.org/pipermail/llvm-dev/2017-October/118673.html>
>    - Using C++14 code in LLVM (2016)
>   
<http://lists.llvm.org/pipermail/llvm-dev/2016-October/105483.html>
>    - Document and Enforce new Host Compiler Policy
>    <http://llvm.org/D47073>
>    - Require GCC 5.1 and LLVM 3.5 at a minimum
<http://llvm.org/D46723>
>
>
> *Migrate to what?*
>
> I’m only proposing that we migrate to C++14 for now. If you want to
> propose C++17, please do the work required by the policy. In particular,
> document which toolchains this would require, and what features you’d
> unlock. As per policy, I want to start soft-errors when building LLVM 8, so
> that LLVM 9 can use more than C++11.
>
>
> *Timeline*
>
> At the LLVM dev meeting BoF, the room already agreed to move past C++11.
> Late March 2019 was proposed as a time when we’d start migrating, pending
> large contributors’ readiness. I’m sticking to that timeline, we’ll see if
> everyone is ready at the end of March. I nonetheless want to get the
> soft-errors into the LLVM 8 branch so that we give a sufficient heads-up to
> developers who only compile releases.
>
>
> *Upsides*
>
> One clear upside of dropping older toolchains: they don’t even support
> C++11 very well. We have a handful of workarounds left in ADT (particularly
> around type traits) and I’d like to get rid of them.
>
> The compiler versions I propose allow us to use all of C++14, which
> includes:
>
>    - Binary literals
>   
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf>
>    - decltype(auto), Return type deduction for normal functions
>   
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3638.html>
>    - Initialized/Generalized lambda captures (init-capture)
>   
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3648.html>
>    - Generic (polymorphic) lambda expressions
>   
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3649.html>
>    - Variable templates
>   
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3651.pdf>
>    - Member initializers and aggregates (NSDMI)
>   
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3653.html>
>    - A bunch of new constexpr language and library features
>    - Various other language and library features
>
> See CppReference <https://en.cppreference.com/w/cpp/compiler_support>
for
> details.
>
> Of these, I think polymorphic lambdas are the big feature. Of course, just
> like Almost Always Auto, we should use such things only where it makes
> sense.
>
>
> *Toolchains*
>
> We’re currently mandating:
>
>    - Clang 3.1 (*released 2012/05*)
>    - Apple Clang 3.1 (*released 2012/05*)
>    - GCC 4.8 (*released 2013/03*)
>    - Visual Studio 2015 (Update 3) (*released 2016/06*)
>
> I propose instead:
>
>    - Clang 3.5 (*released 2014/07*) to get -std=c++14 instead of
>    -std=c++1y
>    - Apple Clang 6.0 (*released 2014/07*) to match clang 3.5
>    - GCC 5.1 (*released 2015/04*) because C++14 mostly came to be in GCC 5
>    - Visual Studio 2017 (*released 2017/03*) so that we get extended
>    constexpr and NSDMI
>
> Version information from:
>
>    - Clang http://releases.llvm.org
>    - Apple clang https://trac.macports.org/wiki/XcodeVersionInfo and
>    https://en.wikipedia.org/wiki/Xcode#Latest_versions
>    - GCC https://gcc.gnu.org/releases.html
>    - MSVC https://en.wikipedia.org/wiki/Microsoft_Visual_Studio and
>    https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance
>
>
> My previous attempts pointed out that WebKit / Chromium / Firefox are all
> past C++11 (WebKit is moving to C++17
>
<https://lists.webkit.org/pipermail/webkit-dev/2018-March/029922.html>
(from
> C++14), Chromium started moving to C++14
>
<https://groups.google.com/a/chromium.org/d/msg/cxx/ow7hmdDm4yw/eV6KWL2yAQAJ>,
> Firefox uses some C++14
>
<https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code>).
> This means that platforms which distribute a modern browser can already
> bootstrap a browser. That’s a nice datapoint, but isn’t sufficient for
> platforms which compile / use LLVM (especially as a library).
>
> Here’s a table from the LLVM dev meeting BoF detailing version info for
> distros that seemed relevant:
>
> *Release*
> *Distro*
> *Compiler*
> *C++14 lang*
> *2003-10*
> RHEL 3
> GCC 3.2
> ❌
> *2005-02*
> RHEL 4
> GCC 3.4
> ❌
> *2007-03*
> RHEL 5
> GCC 4.1
> ❌
> *2010-11*
> RHEL 6
> GCC 4.4
> ❌
> *2013-05*
> Debian 7 wheezy
> GCC 4.7.2
> ❌
> *2013-12*
> RHEL 7
> GCC 4.8
> ❌
> *2015-04*
> Debian 8 jessie
> GCC 4.9.2
> ❌
> *2015-05*
> OpenBSD 5.7
> LLVM 3.5
> ✅
> *2015-10*
> OpenBSD 5.8
> LLVM 3.5
> ✅
> *2016-03*
> OpenBSD 5.9
> LLVM 3.5
> ✅
> *2016-04*
> Ubuntu 14.04
> GCC 4.8.2
> ❌
> *2016-04*
> Ubuntu 16.04
> GCC 5.3.1
> ✅
> *2016-09*
> OpenBSD 6.0
> LLVM 3.8
> ✅
> *2017-04*
> OpenBSD 6.1
> LLVM 4.0.0
> ✅
> *2017-06*
> Debian 9 stretch
> GCC 6.3.0
> ✅
> *2017-10*
> Ubuntu 17.10
> GCC 7.2.0
> ✅
> *2017-10*
> OpenBSD 6.2
> LLVM 5.0.0
> ✅
> *2018-04*
> Ubuntu 18.04
> GCC 7.3.0
> ✅
> *2018-04*
> OpenBSD 6.3
> LLVM 5.0.1
> ✅
> *2018-10*
> Ubuntu 18.10
> GCC 8.1.0
> ✅
> *2018-??*
> Debian 10 buster
> GCC 8.1.0
> ✅
>
> The data comes from the following sources:
>
>    - https://en.cppreference.com/w/cpp/compiler_support
>    - https://packages.ubuntu.com/search?keywords=gcc
>    - https://packages.debian.org/search?keywords=gcc
>    - https://access.redhat.com/solutions/19458
>    - https://www.openbsd.org/63.html
>    - https://en.wikipedia.org/wiki/Clang
>    - https://releases.llvm.org
>
> I haven’t documented FreeBSD / NetBSD / Fedora / MacOS / MSVC, and nobody
> complained at the BoF. I’d like to understand if we should care about
> documenting these: ideally the toolchain update policy would list which
> platforms need to be considered and how far back in time is relevant.
>
> Thanks,
>
> JF
> _______________________________________________
> 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
> https://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/20190125/e58610ef/attachment.html>

Hubert Tong via llvm-dev

2019-Jan-31 04:31 UTC

head link

[llvm-dev] [RFC] migrating past C++11

On Tue, Jan 22, 2019 at 5:12 PM Josh Stone via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 1/22/19 1:44 PM, JF Bastien via llvm-dev wrote:
>
> *Release*
> *Distro*
> *Compiler*
> *C++14 lang*
> *2003-10*
> RHEL 3
> GCC 3.2
> ❌
> *2005-02*
> RHEL 4
> GCC 3.4
> ❌
> *2007-03*
> RHEL 5
> GCC 4.1
> ❌
> *2010-11*
> RHEL 6
> GCC 4.4
> ❌
> *2013-12*
> RHEL 7
> GCC 4.8
> ❌
>
> For RHEL's sake, note that one can get newer GCC here:
>
> https://developers.redhat.com/products/developertoolset/overview/
>It seems that the "newer GCC" made available there uses the pre-C++11
ABI:
https://bugzilla.redhat.com/show_bug.cgi?id=1546704. So, the current
proposal could be ambiguous about whether the toolchain from the Red Hat
Developer Toolset for RHEL 7 would be a supported toolchain going forward
(assuming the GCC version number is new enough).

> _______________________________________________
> 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/20190130/849c9d6b/attachment.html>

JF Bastien via llvm-dev

2019-Apr-01 20:16 UTC

head link

[llvm-dev] [RFC] migrating LLVM to C++14

Hello folks (except fans of April 1st: this is not a joke),

We discussed migrating past C++11
<http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html>
recently and got consensus. This led us to bump our minimum toolchain
requirements <https://reviews.llvm.org/D57264> to a point where C++14 was
supported by all compilers. Following our policy
<http://llvm.org/docs/DeveloperPolicy.html#toolchain>, I’m now suggesting
that we make this official by creating a patch which will:

Update the C++ standard version
<http://llvm.org/docs/CodingStandards.html#c-standard-versions> to C++14,
allowing the usage of the following language and library features:
Binary literals <https://wg21.link/N3472>:
Without restrictions.
decltype(auto) <https://wg21.link/N3638>, Return type deduction for normal
functions:
As with auto
<http://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable>,
only where it makes code more readable.
Initialized/Generalized lambda captures (init-capture)
<https://wg21.link/N3648>:
Without restriction.
Generic (polymorphic) lambda expressions <https://wg21.link/N3649>:
As with auto
<http://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable>,
only where it makes code more readable.
Variable templates <https://wg21.link/N3651>:
Without restriction.
Member initializers and aggregates (NSDMI) <https://wg21.link/N3653>:
Without restriction.
More constexpr everywhere:
Without restriction.
Single quote as digit separator <https://wg21.link/N3781>:
Not allowed.
std::quoted <https://wg21.link/N3654>:
Without restriction.
std::exchange <https://wg21.link/N3668>:
Without restriction.
Change the minimum toolchain requirement from a “soft-error” to a “hard-error”
such that CheckCompilerVersion.cmake now says:
set(GCC_MIN 5.1)
set(GCC_SOFT_ERROR 5.1)
set(CLANG_MIN 3.5)
set(CLANG_SOFT_ERROR 3.5)
set(APPLECLANG_MIN 6.0)
set(APPLECLANG_SOFT_ERROR 6.0)
set(MSVC_MIN 19.1)
set(MSVC_SOFT_ERROR 19.1)
The above makes LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN useless until we try
upgrading toolchain versions again.
Use C++14 in the code somewhere.

When we last discussed this we said we’d revisit at the end of March 2019 and
see if everyone was able to upgrade their toolchains. Remember that by now any
build of LLVM with an old toolchain has received a “soft-error” which people had
to read and disable using a CMake argument. This includes anyone building LLVM 8
because the change made it to the branch. There were plenty of discussions on
Phabricator, on the mailing lists, and at the dev meeting. The was a PSA
<http://lists.llvm.org/pipermail/llvm-dev/2019-February/130117.html> and
emails were sent to all bot maintainers with older bots. At this point there’s
no way that you didn’t know that you needed to upgrade you toolchain.

This would mean that LLVM 9 would require a newer toolchain.

Is anyone not ready for this move? If so, what does your timing look like?

Thanks,

JF


> On Jan 22, 2019, at 1:44 PM, JF Bastien via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Hello fans of the auto keyword!
> 
> We now have a policy on how LLVM toolchains get updated
<https://reviews.llvm.org/rL351765>! Let’s put that policy to good use,
and talk about how we’ll move all monorepo projects past C++11.
> 
> 
> Previous Discussions
> LLVM dev meeting 2018 BoF "Migrating to C++14, and beyond!
<http://llvm.org/devmtg/2018-10/talk-abstracts.html#bof3>"
> A Short Policy Proposal Regarding Host Compilers
<http://lists.llvm.org/pipermail/llvm-dev/2018-May/123238.html>
> Using C++14 code in LLVM (2018)
<http://lists.llvm.org/pipermail/llvm-dev/2018-May/123182.html>
> Using C++14 code in LLVM (2017)
<http://lists.llvm.org/pipermail/llvm-dev/2017-October/118673.html>
> Using C++14 code in LLVM (2016)
<http://lists.llvm.org/pipermail/llvm-dev/2016-October/105483.html>
> Document and Enforce new Host Compiler Policy
<http://llvm.org/D47073>
> Require GCC 5.1 and LLVM 3.5 at a minimum <http://llvm.org/D46723>
> 
> Migrate to what?
> 
> I’m only proposing that we migrate to C++14 for now. If you want to propose
C++17, please do the work required by the policy. In particular, document which
toolchains this would require, and what features you’d unlock. As per policy, I
want to start soft-errors when building LLVM 8, so that LLVM 9 can use more than
C++11.
> 
> 
> Timeline
> 
> At the LLVM dev meeting BoF, the room already agreed to move past C++11.
Late March 2019 was proposed as a time when we’d start migrating, pending large
contributors’ readiness. I’m sticking to that timeline, we’ll see if everyone is
ready at the end of March. I nonetheless want to get the soft-errors into the
LLVM 8 branch so that we give a sufficient heads-up to developers who only
compile releases.
> 
> 
> Upsides
> 
> One clear upside of dropping older toolchains: they don’t even support
C++11 very well. We have a handful of workarounds left in ADT (particularly
around type traits) and I’d like to get rid of them.
> 
> The compiler versions I propose allow us to use all of C++14, which
includes:
> Binary literals
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf>
> decltype(auto), Return type deduction for normal functions
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3638.html>
> Initialized/Generalized lambda captures (init-capture)
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3648.html>
> Generic (polymorphic) lambda expressions
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3649.html>
> Variable templates
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3651.pdf>
> Member initializers and aggregates (NSDMI)
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3653.html>
> A bunch of new constexpr language and library features
> Various other language and library features
> See CppReference <https://en.cppreference.com/w/cpp/compiler_support>
for details.
> 
> Of these, I think polymorphic lambdas are the big feature. Of course, just
like Almost Always Auto, we should use such things only where it makes sense.
> 
> 
> Toolchains
> 
> We’re currently mandating:
> Clang 3.1 (released 2012/05)
> Apple Clang 3.1 (released 2012/05)
> GCC 4.8 (released 2013/03)
> Visual Studio 2015 (Update 3) (released 2016/06)
> I propose instead:
> Clang 3.5 (released 2014/07) to get -std=c++14 instead of -std=c++1y
> Apple Clang 6.0 (released 2014/07) to match clang 3.5
> GCC 5.1 (released 2015/04) because C++14 mostly came to be in GCC 5
> Visual Studio 2017 (released 2017/03) so that we get extended constexpr and
NSDMI
> Version information from:
> Clang http://releases.llvm.org <http://releases.llvm.org/>
> Apple clang https://trac.macports.org/wiki/XcodeVersionInfo
<https://trac.macports.org/wiki/XcodeVersionInfo> and
https://en.wikipedia.org/wiki/Xcode#Latest_versions
<https://en.wikipedia.org/wiki/Xcode#Latest_versions>
> GCC https://gcc.gnu.org/releases.html
<https://gcc.gnu.org/releases.html>
> MSVC https://en.wikipedia.org/wiki/Microsoft_Visual_Studio
<https://en.wikipedia.org/wiki/Microsoft_Visual_Studio> and
https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance
<https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance>
> 
> My previous attempts pointed out that WebKit / Chromium / Firefox are all
past C++11 (WebKit is moving to C++17
<https://lists.webkit.org/pipermail/webkit-dev/2018-March/029922.html>
(from C++14), Chromium started moving to C++14
<https://groups.google.com/a/chromium.org/d/msg/cxx/ow7hmdDm4yw/eV6KWL2yAQAJ>,
Firefox uses some C++14
<https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code>).
This means that platforms which distribute a modern browser can already
bootstrap a browser. That’s a nice datapoint, but isn’t sufficient for platforms
which compile / use LLVM (especially as a library).
> 
> Here’s a table from the LLVM dev meeting BoF detailing version info for
distros that seemed relevant:
> 
> Release
> Distro
> Compiler
> C++14 lang
> 2003-10
> RHEL 3
> GCC 3.2
> ❌
> 2005-02
> RHEL 4
> GCC 3.4
> ❌
> 2007-03
> RHEL 5
> GCC 4.1
> ❌
> 2010-11
> RHEL 6
> GCC 4.4
> ❌
> 2013-05
> Debian 7 wheezy
> GCC 4.7.2
> ❌
> 2013-12
> RHEL 7
> GCC 4.8
> ❌
> 2015-04
> Debian 8 jessie
> GCC 4.9.2
> ❌
> 2015-05
> OpenBSD 5.7
> LLVM 3.5
> ✅
> 2015-10
> OpenBSD 5.8
> LLVM 3.5
> ✅
> 2016-03
> OpenBSD 5.9
> LLVM 3.5
> ✅
> 2016-04
> Ubuntu 14.04
> GCC 4.8.2
> ❌
> 2016-04
> Ubuntu 16.04
> GCC 5.3.1
> ✅
> 2016-09
> OpenBSD 6.0
> LLVM 3.8
> ✅
> 2017-04
> OpenBSD 6.1
> LLVM 4.0.0
> ✅
> 2017-06
> Debian 9 stretch
> GCC 6.3.0
> ✅
> 2017-10
> Ubuntu 17.10
> GCC 7.2.0
> ✅
> 2017-10
> OpenBSD 6.2
> LLVM 5.0.0
> ✅
> 2018-04
> Ubuntu 18.04
> GCC 7.3.0
> ✅
> 2018-04
> OpenBSD 6.3
> LLVM 5.0.1
> ✅
> 2018-10
> Ubuntu 18.10
> GCC 8.1.0
> ✅
> 2018-??
> Debian 10 buster
> GCC 8.1.0
> ✅
> 
> The data comes from the following sources:
> https://en.cppreference.com/w/cpp/compiler_support
<https://en.cppreference.com/w/cpp/compiler_support>
> https://packages.ubuntu.com/search?keywords=gcc
<https://packages.ubuntu.com/search?keywords=gcc>
> https://packages.debian.org/search?keywords=gcc
<https://packages.debian.org/search?keywords=gcc>
> https://access.redhat.com/solutions/19458
<https://access.redhat.com/solutions/19458>
> https://www.openbsd.org/63.html <https://www.openbsd.org/63.html>
> https://en.wikipedia.org/wiki/Clang
<https://en.wikipedia.org/wiki/Clang>
> https://releases.llvm.org <https://releases.llvm.org/>
> I haven’t documented FreeBSD / NetBSD / Fedora / MacOS / MSVC, and nobody
complained at the BoF. I’d like to understand if we should care about
documenting these: ideally the toolchain update policy would list which
platforms need to be considered and how far back in time is relevant.
> 
> Thanks,
> 
> JF
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190401/76a0326f/attachment.html>

Chandler Carruth via llvm-dev

2019-Apr-01 23:07 UTC

head link

[llvm-dev] [RFC] migrating LLVM to C++14

On Mon, Apr 1, 2019 at 1:16 PM JF Bastien via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hello folks (except fans of April 1st: this is *not* a joke),
>
> We discussed migrating past C++11
> <http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html>
recently
> and got consensus. This led us to bump our minimum toolchain requirements
> <https://reviews.llvm.org/D57264> to a point where C++14 was
supported by
> all compilers. Following our policy
> <http://llvm.org/docs/DeveloperPolicy.html#toolchain>, I’m now
suggesting
> that we make this official by creating a patch which will:
>
>
>    - Update the C++ standard version
>    <http://llvm.org/docs/CodingStandards.html#c-standard-versions> to
>    C++14, allowing the usage of the following language and library
features:
>       - Binary literals <https://wg21.link/N3472>:
>          - Without restrictions.
>       - decltype(auto) <https://wg21.link/N3638>, Return type
deduction
>       for normal functions:
>          - As with auto
>         
<http://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable>,
>          only where it makes code more readable.
>       - Initialized/Generalized lambda captures (init-capture)
>       <https://wg21.link/N3648>:
>          - Without restriction.
>       - Generic (polymorphic) lambda expressions
<https://wg21.link/N3649>
>       :
>          - As with auto
>         
<http://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable>,
>          only where it makes code more readable.
>       - Variable templates <https://wg21.link/N3651>:
>          - Without restriction.
>       - Member initializers and aggregates (NSDMI)
>       <https://wg21.link/N3653>:
>          - Without restriction.
>       - More constexpr everywhere:
>          - Without restriction.
>       - Single quote as digit separator <https://wg21.link/N3781>:
>          - Not allowed.
>       - std::quoted <https://wg21.link/N3654>:
>          - Without restriction.
>       - std::exchange <https://wg21.link/N3668>:
>          - Without restriction.
>       - Change the minimum toolchain requirement from a “soft-error” to a
>    “hard-error” such that CheckCompilerVersion.cmake now says:
>       - set(GCC_MIN 5.1)
>       set(GCC_SOFT_ERROR 5.1)
>       set(CLANG_MIN 3.5)
>       set(CLANG_SOFT_ERROR 3.5)
>       set(APPLECLANG_MIN 6.0)
>       set(APPLECLANG_SOFT_ERROR 6.0)
>       set(MSVC_MIN 19.1)
>       set(MSVC_SOFT_ERROR 19.1)
>    - The above makes LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN useless until
>    we try upgrading toolchain versions again.
>    - Use C++14 in the code somewhere.
>
>
> When we last discussed this we said we’d revisit at the end of March 2019
> and see if everyone was able to upgrade their toolchains. Remember that by
> now any build of LLVM with an old toolchain has received a “soft-error”
> which people had to read and disable using a CMake argument. This includes
> anyone building LLVM 8 because the change made it to the branch. There were
> plenty of discussions on Phabricator, on the mailing lists, and at the dev
> meeting. The was a PSA
> <http://lists.llvm.org/pipermail/llvm-dev/2019-February/130117.html>
and
> emails were sent to all bot maintainers with older bots. At this point
> there’s no way that you didn’t know that you needed to upgrade you
> toolchain.
>
> This would mean that LLVM 9 would require a newer toolchain.
>
> Is anyone not ready for this move?
>
FWIW, despite making good progress, we're not quite finished.

> If so, what does your timing look like?
>
We are significantly closer than when we last talked (two separate big
milestones landed). We're basically on the last step which, for us, is
switching to libc++. AFAIK, we don't have any major blockers, and folks are
mostly trying to land the necessary changes. Optimistically, we'll finish
in April. Conservatively, it might slip a week or two into May, but that
seems unlikely at this point (there are few unknowns left).

>
> Thanks,
>
> JF
>
>
>
> On Jan 22, 2019, at 1:44 PM, JF Bastien via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hello fans of the auto keyword!
>
> We now have a policy on how LLVM toolchains get updated
> <https://reviews.llvm.org/rL351765>! Let’s put that policy to good
use,
> and talk about how we’ll move all monorepo projects past C++11.
>
>
> *Previous Discussions*
>
>    - LLVM dev meeting 2018 BoF "Migrating to C++14, and beyond!
>    <http://llvm.org/devmtg/2018-10/talk-abstracts.html#bof3>"
>    - A Short Policy Proposal Regarding Host Compilers
>    <http://lists.llvm.org/pipermail/llvm-dev/2018-May/123238.html>
>    - Using C++14 code in LLVM (2018)
>    <http://lists.llvm.org/pipermail/llvm-dev/2018-May/123182.html>
>    - Using C++14 code in LLVM (2017)
>   
<http://lists.llvm.org/pipermail/llvm-dev/2017-October/118673.html>
>    - Using C++14 code in LLVM (2016)
>   
<http://lists.llvm.org/pipermail/llvm-dev/2016-October/105483.html>
>    - Document and Enforce new Host Compiler Policy
>    <http://llvm.org/D47073>
>    - Require GCC 5.1 and LLVM 3.5 at a minimum
<http://llvm.org/D46723>
>
>
> *Migrate to what?*
>
> I’m only proposing that we migrate to C++14 for now. If you want to
> propose C++17, please do the work required by the policy. In particular,
> document which toolchains this would require, and what features you’d
> unlock. As per policy, I want to start soft-errors when building LLVM 8, so
> that LLVM 9 can use more than C++11.
>
>
> *Timeline*
>
> At the LLVM dev meeting BoF, the room already agreed to move past C++11.
> Late March 2019 was proposed as a time when we’d start migrating, pending
> large contributors’ readiness. I’m sticking to that timeline, we’ll see if
> everyone is ready at the end of March. I nonetheless want to get the
> soft-errors into the LLVM 8 branch so that we give a sufficient heads-up to
> developers who only compile releases.
>
>
> *Upsides*
>
> One clear upside of dropping older toolchains: they don’t even support
> C++11 very well. We have a handful of workarounds left in ADT (particularly
> around type traits) and I’d like to get rid of them.
>
> The compiler versions I propose allow us to use all of C++14, which
> includes:
>
>    - Binary literals
>   
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf>
>    - decltype(auto), Return type deduction for normal functions
>   
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3638.html>
>    - Initialized/Generalized lambda captures (init-capture)
>   
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3648.html>
>    - Generic (polymorphic) lambda expressions
>   
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3649.html>
>    - Variable templates
>   
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3651.pdf>
>    - Member initializers and aggregates (NSDMI)
>   
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3653.html>
>    - A bunch of new constexpr language and library features
>    - Various other language and library features
>
> See CppReference <https://en.cppreference.com/w/cpp/compiler_support>
for
> details.
>
> Of these, I think polymorphic lambdas are the big feature. Of course, just
> like Almost Always Auto, we should use such things only where it makes
> sense.
>
>
> *Toolchains*
>
> We’re currently mandating:
>
>    - Clang 3.1 (*released 2012/05*)
>    - Apple Clang 3.1 (*released 2012/05*)
>    - GCC 4.8 (*released 2013/03*)
>    - Visual Studio 2015 (Update 3) (*released 2016/06*)
>
> I propose instead:
>
>    - Clang 3.5 (*released 2014/07*) to get -std=c++14 instead of
>    -std=c++1y
>    - Apple Clang 6.0 (*released 2014/07*) to match clang 3.5
>    - GCC 5.1 (*released 2015/04*) because C++14 mostly came to be in GCC 5
>    - Visual Studio 2017 (*released 2017/03*) so that we get extended
>    constexpr and NSDMI
>
> Version information from:
>
>    - Clang http://releases.llvm.org
>    - Apple clang https://trac.macports.org/wiki/XcodeVersionInfo and
>    https://en.wikipedia.org/wiki/Xcode#Latest_versions
>    - GCC https://gcc.gnu.org/releases.html
>    - MSVC https://en.wikipedia.org/wiki/Microsoft_Visual_Studio and
>    https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance
>
>
> My previous attempts pointed out that WebKit / Chromium / Firefox are all
> past C++11 (WebKit is moving to C++17
>
<https://lists.webkit.org/pipermail/webkit-dev/2018-March/029922.html>
(from
> C++14), Chromium started moving to C++14
>
<https://groups.google.com/a/chromium.org/d/msg/cxx/ow7hmdDm4yw/eV6KWL2yAQAJ>,
> Firefox uses some C++14
>
<https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code>).
> This means that platforms which distribute a modern browser can already
> bootstrap a browser. That’s a nice datapoint, but isn’t sufficient for
> platforms which compile / use LLVM (especially as a library).
>
> Here’s a table from the LLVM dev meeting BoF detailing version info for
> distros that seemed relevant:
>
> *Release*
> *Distro*
> *Compiler*
> *C++14 lang*
> *2003-10*
> RHEL 3
> GCC 3.2
> ❌
> *2005-02*
> RHEL 4
> GCC 3.4
> ❌
> *2007-03*
> RHEL 5
> GCC 4.1
> ❌
> *2010-11*
> RHEL 6
> GCC 4.4
> ❌
> *2013-05*
> Debian 7 wheezy
> GCC 4.7.2
> ❌
> *2013-12*
> RHEL 7
> GCC 4.8
> ❌
> *2015-04*
> Debian 8 jessie
> GCC 4.9.2
> ❌
> *2015-05*
> OpenBSD 5.7
> LLVM 3.5
> ✅
> *2015-10*
> OpenBSD 5.8
> LLVM 3.5
> ✅
> *2016-03*
> OpenBSD 5.9
> LLVM 3.5
> ✅
> *2016-04*
> Ubuntu 14.04
> GCC 4.8.2
> ❌
> *2016-04*
> Ubuntu 16.04
> GCC 5.3.1
> ✅
> *2016-09*
> OpenBSD 6.0
> LLVM 3.8
> ✅
> *2017-04*
> OpenBSD 6.1
> LLVM 4.0.0
> ✅
> *2017-06*
> Debian 9 stretch
> GCC 6.3.0
> ✅
> *2017-10*
> Ubuntu 17.10
> GCC 7.2.0
> ✅
> *2017-10*
> OpenBSD 6.2
> LLVM 5.0.0
> ✅
> *2018-04*
> Ubuntu 18.04
> GCC 7.3.0
> ✅
> *2018-04*
> OpenBSD 6.3
> LLVM 5.0.1
> ✅
> *2018-10*
> Ubuntu 18.10
> GCC 8.1.0
> ✅
> *2018-??*
> Debian 10 buster
> GCC 8.1.0
> ✅
>
> The data comes from the following sources:
>
>    - https://en.cppreference.com/w/cpp/compiler_support
>    - https://packages.ubuntu.com/search?keywords=gcc
>    - https://packages.debian.org/search?keywords=gcc
>    - https://access.redhat.com/solutions/19458
>    - https://www.openbsd.org/63.html
>    - https://en.wikipedia.org/wiki/Clang
>    - https://releases.llvm.org
>
> I haven’t documented FreeBSD / NetBSD / Fedora / MacOS / MSVC, and nobody
> complained at the BoF. I’d like to understand if we should care about
> documenting these: ideally the toolchain update policy would list which
> platforms need to be considered and how far back in time is relevant.
>
> Thanks,
>
> JF
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://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/20190401/b4e2784c/attachment-0001.html>

Philip Reames via llvm-dev

2019-Apr-02 16:08 UTC

head link

[llvm-dev] [RFC] migrating LLVM to C++14

I was the other major objector at the dev meeting.  I can confirm that
we've successfully migrated and no longer have any concerns with the
proposed toolchain.

Philip

On 4/1/19 1:16 PM, JF Bastien via llvm-dev wrote:> Hello folks (except fans of April 1st: this is /not/ a joke),
>
> We discussed migrating past C++11
>
<http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html> recently
> and got consensus. This led us to bump our minimum toolchain
> requirements <https://reviews.llvm.org/D57264> to a point where C++14
> was supported by all compilers. Following our policy
> <http://llvm.org/docs/DeveloperPolicy.html#toolchain>, I’m now
> suggesting that we make this official by creating a patch which will:
>
>   * Update the C++ standard version
>    
<http://llvm.org/docs/CodingStandards.html#c-standard-versions> to
>     C++14, allowing the usage of the following language and library
>     features:
>       o Binary literals <https://wg21.link/N3472>:
>           + Without restrictions.
>       o decltype(auto) <https://wg21.link/N3638>, Return type
>         deduction for normal functions:
>           + As with auto
>            
<http://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable>,
>             only where it makes code more readable.
>       o Initialized/Generalized lambda captures (init-capture)
>         <https://wg21.link/N3648>:
>           + Without restriction.
>       o Generic (polymorphic) lambda expressions
>         <https://wg21.link/N3649>:
>           + As with auto
>            
<http://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable>,
>             only where it makes code more readable.
>       o Variable templates <https://wg21.link/N3651>:
>           + Without restriction.
>       o Member initializers and aggregates (NSDMI)
>         <https://wg21.link/N3653>:
>           + Without restriction.
>       o More constexpr everywhere:
>           + Without restriction.
>       o Single quote as digit separator <https://wg21.link/N3781>:
>           + Not allowed.
>       o std::quoted <https://wg21.link/N3654>:
>           + Without restriction.
>       o std::exchange <https://wg21.link/N3668>:
>           + Without restriction.
>   * Change the minimum toolchain requirement from a “soft-error” to a
>     “hard-error” such that CheckCompilerVersion.cmake now says:
>       o set(GCC_MIN 5.1)
>         set(GCC_SOFT_ERROR 5.1)
>         set(CLANG_MIN 3.5)
>         set(CLANG_SOFT_ERROR 3.5)
>         set(APPLECLANG_MIN 6.0)
>         set(APPLECLANG_SOFT_ERROR 6.0)
>         set(MSVC_MIN 19.1)
>         set(MSVC_SOFT_ERROR 19.1)
>   * The above makes LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN useless until
>     we try upgrading toolchain versions again.
>   * Use C++14 in the code somewhere.
>
>
> When we last discussed this we said we’d revisit at the end of March
> 2019 and see if everyone was able to upgrade their toolchains.
> Remember that by now any build of LLVM with an old toolchain has
> received a “soft-error” which people had to read and disable using a
> CMake argument. This includes anyone building LLVM 8 because the
> change made it to the branch. There were plenty of discussions on
> Phabricator, on the mailing lists, and at the dev meeting. The was a
> PSA
>
<http://lists.llvm.org/pipermail/llvm-dev/2019-February/130117.html> and
> emails were sent to all bot maintainers with older bots. At this point
> there’s no way that you didn’t know that you needed to upgrade you
> toolchain.
>
> This would mean that LLVM 9 would require a newer toolchain.
>
> Is anyone not ready for this move? If so, what does your timing look like?
>
> Thanks,
>
> JF
>
>
>
>> On Jan 22, 2019, at 1:44 PM, JF Bastien via llvm-dev
>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
>>
>> Hello fans of the auto keyword!
>>
>> We now have a policy on how LLVM toolchains get updated
>> <https://reviews.llvm.org/rL351765>! Let’s put that policy to
good
>> use, and talk about how we’ll move all monorepo projects past C++11.
>>
>>
>> *Previous Discussions*
>>
>>   * LLVM dev meeting 2018 BoF "Migrating to C++14, and beyond!
>>    
<http://llvm.org/devmtg/2018-10/talk-abstracts.html#bof3>"
>>   * A Short Policy Proposal Regarding Host Compilers
>>    
<http://lists.llvm.org/pipermail/llvm-dev/2018-May/123238.html>
>>   * Using C++14 code in LLVM (2018)
>>    
<http://lists.llvm.org/pipermail/llvm-dev/2018-May/123182.html>
>>   * Using C++14 code in LLVM (2017)
>>    
<http://lists.llvm.org/pipermail/llvm-dev/2017-October/118673.html>
>>   * Using C++14 code in LLVM (2016)
>>    
<http://lists.llvm.org/pipermail/llvm-dev/2016-October/105483.html>
>>   * Document and Enforce new Host Compiler Policy
>>     <http://llvm.org/D47073>
>>   * Require GCC 5.1 and LLVM 3.5 at a minimum
<http://llvm.org/D46723>
>>
>> *
>> *
>> *Migrate to what?*
>>
>> I’m only proposing that we migrate to C++14 for now. If you want to
>> propose C++17, please do the work required by the policy. In
>> particular, document which toolchains this would require, and what
>> features you’d unlock. As per policy, I want to start soft-errors
>> when building LLVM 8, so that LLVM 9 can use more than C++11.
>>
>>
>> *Timeline*
>>
>> At the LLVM dev meeting BoF, the room already agreed to move past
>> C++11. Late March 2019 was proposed as a time when we’d start
>> migrating, pending large contributors’ readiness. I’m sticking to
>> that timeline, we’ll see if everyone is ready at the end of March. I
>> nonetheless want to get the soft-errors into the LLVM 8 branch so
>> that we give a sufficient heads-up to developers who only compile
>> releases.
>>
>>
>> *Upsides*
>>
>> One clear upside of dropping older toolchains: they don’t even
>> support C++11 very well. We have a handful of workarounds left in ADT
>> (particularly around type traits) and I’d like to get rid of them.
>>
>> The compiler versions I propose allow us to use all of C++14, which
>> includes:
>>
>>   * Binary literals
>>    
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf>
>>   * decltype(auto), Return type deduction for normal functions
>>    
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3638.html>
>>   * Initialized/Generalized lambda captures (init-capture)
>>    
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3648.html>
>>   * Generic (polymorphic) lambda expressions
>>    
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3649.html>
>>   * Variable templates
>>    
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3651.pdf>
>>   * Member initializers and aggregates (NSDMI)
>>    
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3653.html>
>>   * A bunch of new constexpr language and library features
>>   * Various other language and library features
>>
>> See CppReference
>> <https://en.cppreference.com/w/cpp/compiler_support> for details.
>>
>> Of these, I think polymorphic lambdas are the big feature. Of course,
>> just like Almost Always Auto, we should use such things only where it
>> makes sense.
>>
>>
>> *Toolchains*
>>
>> We’re currently mandating:
>>
>>   * Clang 3.1 (/released 2012/05/)
>>   * Apple Clang 3.1 (/released 2012/05/)
>>   * GCC 4.8 (/released 2013/03/)
>>   * Visual Studio 2015 (Update 3) (/released 2016/06/)
>>
>> I propose instead:
>>
>>   * Clang 3.5 (/released 2014/07/) to get -std=c++14 instead
>>     of -std=c++1y
>>   * Apple Clang 6.0 (/released 2014/07/) to match clang 3.5
>>   * GCC 5.1 (/released 2015/04/) because C++14 mostly came to be in GCC
5
>>   * Visual Studio 2017 (/released 2017/03/) so that we get extended
>>     constexpr and NSDMI
>>
>> Version information from:
>>
>>   * Clang http://releases.llvm.org <http://releases.llvm.org/>
>>   * Apple
>>    
clang https://trac.macports.org/wiki/XcodeVersionInfo and https://en.wikipedia.org/wiki/Xcode#Latest_versions
>>   * GCC https://gcc.gnu.org/releases.html
>>   *
MSVC https://en.wikipedia.org/wiki/Microsoft_Visual_Studio and https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance
>>
>>
>> My previous attempts pointed out that WebKit / Chromium / Firefox are
>> all past C++11 (WebKit is moving to C++17
>>
<https://lists.webkit.org/pipermail/webkit-dev/2018-March/029922.html> (from
>> C++14), Chromium started moving to C++14
>>
<https://groups.google.com/a/chromium.org/d/msg/cxx/ow7hmdDm4yw/eV6KWL2yAQAJ>,
>> Firefox uses some C++14
>>
<https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code>).
>> This means that platforms which distribute a modern browser can
>> already bootstrap a browser. That’s a nice datapoint, but isn’t
>> sufficient for platforms which compile / use LLVM (especially as a
>> library).
>>
>> Here’s a table from the LLVM dev meeting BoF detailing version info
>> for distros that seemed relevant:
>>
>> *Release*
>> 	
>> *Distro*
>> 	
>> *Compiler*
>> 	
>> *C++14 lang*
>> *2003-10*
>> 	
>> RHEL 3
>> 	
>> GCC 3.2
>> 	
>> ❌
>> *2005-02*
>> 	
>> RHEL 4
>> 	
>> GCC 3.4
>> 	
>> ❌
>> *2007-03*
>> 	
>> RHEL 5
>> 	
>> GCC 4.1
>> 	
>> ❌
>> *2010-11*
>> 	
>> RHEL 6
>> 	
>> GCC 4.4
>> 	
>> ❌
>> *2013-05*
>> 	
>> Debian 7 wheezy
>> 	
>> GCC 4.7.2
>> 	
>> ❌
>> *2013-12*
>> 	
>> RHEL 7
>> 	
>> GCC 4.8
>> 	
>> ❌
>> *2015-04*
>> 	
>> Debian 8 jessie
>> 	
>> GCC 4.9.2
>> 	
>> ❌
>> *2015-05*
>> 	
>> OpenBSD 5.7
>> 	
>> LLVM 3.5
>> 	
>> ✅
>> *2015-10*
>> 	
>> OpenBSD 5.8
>> 	
>> LLVM 3.5
>> 	
>> ✅
>> *2016-03*
>> 	
>> OpenBSD 5.9
>> 	
>> LLVM 3.5
>> 	
>> ✅
>> *2016-04*
>> 	
>> Ubuntu 14.04
>> 	
>> GCC 4.8.2
>> 	
>> ❌
>> *2016-04*
>> 	
>> Ubuntu 16.04
>> 	
>> GCC 5.3.1
>> 	
>> ✅
>> *2016-09*
>> 	
>> OpenBSD 6.0
>> 	
>> LLVM 3.8
>> 	
>> ✅
>> *2017-04*
>> 	
>> OpenBSD 6.1
>> 	
>> LLVM 4.0.0
>> 	
>> ✅
>> *2017-06*
>> 	
>> Debian 9 stretch
>> 	
>> GCC 6.3.0
>> 	
>> ✅
>> *2017-10*
>> 	
>> Ubuntu 17.10
>> 	
>> GCC 7.2.0
>> 	
>> ✅
>> *2017-10*
>> 	
>> OpenBSD 6.2
>> 	
>> LLVM 5.0.0
>> 	
>> ✅
>> *2018-04*
>> 	
>> Ubuntu 18.04
>> 	
>> GCC 7.3.0
>> 	
>> ✅
>> *2018-04*
>> 	
>> OpenBSD 6.3
>> 	
>> LLVM 5.0.1
>> 	
>> ✅
>> *2018-10*
>> 	
>> Ubuntu 18.10
>> 	
>> GCC 8.1.0
>> 	
>> ✅
>> *2018-??*
>> 	
>> Debian 10 buster
>> 	
>> GCC 8.1.0
>> 	
>> ✅
>>
>>
>> The data comes from the following sources:
>>
>>   * https://en.cppreference.com/w/cpp/compiler_support
>>   * https://packages.ubuntu.com/search?keywords=gcc
>>   * https://packages.debian.org/search?keywords=gcc
>>   * https://access.redhat.com/solutions/19458
>>   * https://www.openbsd.org/63.html
>>   * https://en.wikipedia.org/wiki/Clang
>>   * https://releases.llvm.org <https://releases.llvm.org/>
>>
>> I haven’t documented FreeBSD / NetBSD / Fedora / MacOS / MSVC, and
>> nobody complained at the BoF. I’d like to understand if we should
>> care about documenting these: ideally the toolchain update policy
>> would list which platforms need to be considered and how far back in
>> time is relevant.
>>
>> Thanks,
>>
>> JF
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://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/20190402/70cec9eb/attachment-0001.html>

David Greene via llvm-dev

2019-Apr-03 16:36 UTC

head link

[llvm-dev] [RFC] migrating LLVM to C++14

JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> writes:
> * Single quote as digit separator:
>
> * Not allowed.
Just out of curiosity, why?  I can see it wreaking havoc for some syntax
highlighters, but are there other reasons?

                        -David

Ed Maste via llvm-dev

2019-Apr-08 20:57 UTC

head link

[llvm-dev] [RFC] migrating LLVM to C++14

On Mon, 1 Apr 2019 at 16:16, JF Bastien via llvm-dev
<llvm-dev at lists.llvm.org> wrote:>
> I haven’t documented FreeBSD / NetBSD / Fedora / MacOS / MSVC, and nobody
complained at the BoF. I’d like to understand if we should care about
documenting these: ideally the toolchain update policy would list which
platforms need to be considered and how far back in time is relevant.
FreeBSD is one of the earlier consistent users of Clang and represents
a large installed base; "we" should care about FreeBSD's tool
chain.

I see your table goes back to 2003 in some cases; I have no interest
in collecting information for FreeBSD versions that are long since
unsupported by the project.

For recent FreeBSD versions I believe we have:

FreeBSD version / LLVM version / Release date / Support end date
10.4 / 3.4.1 / 2017-10 / ended Oct 31, 2018
11.1 / 4.0.0 / 2017-07 / ended Sep 30, 2018
11.2 / 6.0.0 / 2018-06 / current
12.0 / 6.0.1 / 2018-12 / current

Possibly Parallel Threads

Search for more seemingly similar threads

llvm dev - Jan 2019 - [RFC] migrating past C++11

[llvm-dev] [RFC] migrating past C++11

[llvm-dev] [RFC] migrating past C++11

[llvm-dev] [RFC] migrating past C++11

[llvm-dev] [RFC] migrating past C++11

[llvm-dev] [RFC] migrating past C++11

[llvm-dev] [RFC] migrating past C++11

[llvm-dev] [RFC] migrating past C++11

[llvm-dev] [RFC] migrating past C++11

[llvm-dev] [RFC] migrating past C++11

[llvm-dev] [RFC] migrating past C++11

[llvm-dev] [RFC] migrating past C++11

[llvm-dev] [RFC] migrating past C++11

[llvm-dev] [RFC] migrating past C++11

[llvm-dev] [RFC] migrating past C++11

[llvm-dev] [RFC] migrating past C++11

[llvm-dev] [RFC] migrating past C++11

[llvm-dev] [RFC] migrating LLVM to C++14

[llvm-dev] [RFC] migrating LLVM to C++14

[llvm-dev] [RFC] migrating LLVM to C++14

[llvm-dev] [RFC] migrating LLVM to C++14

[llvm-dev] [RFC] migrating LLVM to C++14

Possibly Parallel Threads