[llvm-dev] [RFC] migrating LLVM to C++14
Philip Reames via llvm-dev
llvm-dev at lists.llvm.org
Tue Apr 2 09:08:32 PDT 2019
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>
More information about the llvm-dev
mailing list