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

Thu Jan 24 20:49:26 PST 2019

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