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

Keane, Erich via llvm-commits llvm-commits at lists.llvm.org
Wed Jan 23 06:42:37 PST 2019


For this reason, I think it is absolutely vital that we get the “Soft Error” into the 8.0 branch ASAP.  We should still make sure that 8.0 builds for the older toolchains, but if we release without the flag being there we will most definitely run into people being horribly surprised.

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Philip Reames via llvm-dev
Sent: Tuesday, January 22, 2019 5:42 PM
To: JF Bastien <jfbastien at apple.com>; via llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [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<mailto:llvm-dev at lists.llvm.org>

http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20190123/7c43b9f2/attachment-0001.html>


More information about the llvm-commits mailing list