+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>
The patch is about ready to land, which means any older compiler will soft-error (which you can turn off with LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN). I think we should then cherry-pick the patch to the LLVM 8 branch. The last remaining issue are the buildbots. I audited *all* bots in http://lab.llvm.org:8011/buildslaves <http://lab.llvm.org:8011/buildslaves> (there's so many!). Some of them are down, I therefore have no idea what they run. Here are the bots that will definitely break, with their maintainers: Galina Kistanova <gkistanova at gmail.com> am1i-slv1 -- gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4 as-bldslv4 -- Microsoft (R) Visual Studio (R) 2015 (14.0) ps4-buildslave2 -- Microsoft (R) Visual Studio (R) 2015 (14.0) Hexagon QA <llvm.buildmaster at quicinc.com> hexagon-build-02 -- gcc (Ubuntu 4.9.2-10ubuntu13) 4.9.2 hexagon-build-03 -- gcc (Ubuntu 4.9.2-10ubuntu13) 4.9.2 Vitaly Buka <vitalybuka at google.com> sanitizer-buildbot6 -- gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4 Reid Kleckner <rnk at google.com> sanitizer-windows -- Microsoft (R) Visual Studio (R) 2015 (14.0) Ilia Taraban <mstester.llvm at gmail.com> windows7-buildbot -- Microsoft (R) Visual Studio (R) 2015 (14.0) The maintainers have 3 options: 1. Pass LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN to their bot, suffer breakage later. 2. Update the bot to a newer compiler version. 3. Entirely turn down the bot. I’ve emailed the maintainers and some have already responded. Once all bots are in a good state I’ll commit the patch (unless someone else chimes in with new information).> On Jan 25, 2019, at 5:47 PM, Chandler Carruth <chandlerc at gmail.com> wrote: > > +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 <mailto: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 <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 <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> > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <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/20190129/c56c2149/attachment.html>
All the bots should now be updated, thanks to the maintainers for their fast turnaround! Unless there are new comments I’ll commit the patch tomorrow.> On Jan 29, 2019, at 1:05 PM, JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The patch is about ready to land, which means any older compiler will soft-error (which you can turn off with LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN). I think we should then cherry-pick the patch to the LLVM 8 branch. > > The last remaining issue are the buildbots. I audited *all* bots in http://lab.llvm.org:8011/buildslaves <http://lab.llvm.org:8011/buildslaves> (there's so many!). Some of them are down, I therefore have no idea what they run. Here are the bots that will definitely break, with their maintainers: > > Galina Kistanova <gkistanova at gmail.com <mailto:gkistanova at gmail.com>> > am1i-slv1 -- gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4 > as-bldslv4 -- Microsoft (R) Visual Studio (R) 2015 (14.0) > ps4-buildslave2 -- Microsoft (R) Visual Studio (R) 2015 (14.0) > > Hexagon QA <llvm.buildmaster at quicinc.com <mailto:llvm.buildmaster at quicinc.com>> > hexagon-build-02 -- gcc (Ubuntu 4.9.2-10ubuntu13) 4.9.2 > hexagon-build-03 -- gcc (Ubuntu 4.9.2-10ubuntu13) 4.9.2 > > Vitaly Buka <vitalybuka at google.com <mailto:vitalybuka at google.com>> > sanitizer-buildbot6 -- gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4 > > Reid Kleckner <rnk at google.com <mailto:rnk at google.com>> > sanitizer-windows -- Microsoft (R) Visual Studio (R) 2015 (14.0) > > Ilia Taraban <mstester.llvm at gmail.com <mailto:mstester.llvm at gmail.com>> > windows7-buildbot -- Microsoft (R) Visual Studio (R) 2015 (14.0) > > The maintainers have 3 options: > > 1. Pass LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN to their bot, suffer breakage later. > 2. Update the bot to a newer compiler version. > 3. Entirely turn down the bot. > > I’ve emailed the maintainers and some have already responded. Once all bots are in a good state I’ll commit the patch (unless someone else chimes in with new information). > > >> On Jan 25, 2019, at 5:47 PM, Chandler Carruth <chandlerc at gmail.com <mailto:chandlerc at gmail.com>> wrote: >> >> +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 <mailto: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 <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 <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> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://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/20190130/72f41e5e/attachment.html>
Krzysztof Parzyszek via llvm-dev
2019-Jan-31 14:27 UTC
[llvm-dev] [RFC] migrating past C++11
The hexagon bots use either clang 6 or clang 3.7 (depending on the builder). Both of these compilers are installed in non-standard locations and are not system compilers. I think this is the reason why the bot page shows gcc, but gcc is not used for building clang. -Krzysztof On 1/29/2019 3:05 PM, JF Bastien via llvm-dev wrote:> The patch is about ready to land, which means any older compiler will > soft-error (which you can turn off with > LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN). I think we should then > cherry-pick the patch to the LLVM 8 branch. > > The last remaining issue are the buildbots. I audited *all* bots in > http://lab.llvm.org:8011/buildslaves (there's so many!). Some of them > are down, I therefore have no idea what they run. Here are the bots that > will definitely break, with their maintainers: > > Galina Kistanova <gkistanova at gmail.com <mailto:gkistanova at gmail.com>> > am1i-slv1 -- gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4 > as-bldslv4 -- Microsoft (R) Visual Studio (R) 2015 (14.0) > ps4-buildslave2 -- Microsoft (R) Visual Studio (R) 2015 (14.0) > > Hexagon QA <llvm.buildmaster at quicinc.com > <mailto:llvm.buildmaster at quicinc.com>> > hexagon-build-02 -- gcc (Ubuntu 4.9.2-10ubuntu13) 4.9.2 > hexagon-build-03 -- gcc (Ubuntu 4.9.2-10ubuntu13) 4.9.2 > > Vitaly Buka <vitalybuka at google.com <mailto:vitalybuka at google.com>> > sanitizer-buildbot6 -- gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4 > > Reid Kleckner <rnk at google.com <mailto:rnk at google.com>> > sanitizer-windows -- Microsoft (R) Visual Studio (R) 2015 (14.0) > > Ilia Taraban <mstester.llvm at gmail.com <mailto:mstester.llvm at gmail.com>> > windows7-buildbot -- Microsoft (R) Visual Studio (R) 2015 (14.0) > > > The maintainers have 3 options: > > 1. Pass LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN to their bot, suffer > breakage later. > 2. Update the bot to a newer compiler version. > 3. Entirely turn down the bot. > > I’ve emailed the maintainers and some have already responded. Once all > bots are in a good state I’ll commit the patch (unless someone else > chimes in with new information). > > >> On Jan 25, 2019, at 5:47 PM, Chandler Carruth <chandlerc at gmail.com >> <mailto:chandlerc at gmail.com>> wrote: >> >> +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 <mailto: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 <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 <mailto:llvm-dev at lists.llvm.org> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > > > <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> > Virus-free. www.avg.com > <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >
On Tue, 29 Jan 2019 at 21:05, JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > The patch is about ready to land, which means any older compiler will soft-error (which you can turn off with LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN). I think we should then cherry-pick the patch to the LLVM 8 branch. > > The last remaining issue are the buildbots. I audited *all* bots in http://lab.llvm.org:8011/buildslaves (there's so many!). Some of them are down, I therefore have no idea what they run. Here are the bots that will definitely break, with their maintainers: > > Galina Kistanova <gkistanova at gmail.com> > am1i-slv1 -- gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4 > as-bldslv4 -- Microsoft (R) Visual Studio (R) 2015 (14.0) > ps4-buildslave2 -- Microsoft (R) Visual Studio (R) 2015 (14.0) > > Hexagon QA <llvm.buildmaster at quicinc.com> > hexagon-build-02 -- gcc (Ubuntu 4.9.2-10ubuntu13) 4.9.2 > hexagon-build-03 -- gcc (Ubuntu 4.9.2-10ubuntu13) 4.9.2 > > Vitaly Buka <vitalybuka at google.com> > sanitizer-buildbot6 -- gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4 > > Reid Kleckner <rnk at google.com> > sanitizer-windows -- Microsoft (R) Visual Studio (R) 2015 (14.0) > > Ilia Taraban <mstester.llvm at gmail.com> > windows7-buildbot -- Microsoft (R) Visual Studio (R) 2015 (14.0) > > > The maintainers have 3 options: > > 1. Pass LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN to their bot, suffer breakage later. > 2. Update the bot to a newer compiler version. > 3. Entirely turn down the bot. > > I’ve emailed the maintainers and some have already responded. Once all bots are in a good state I’ll commit the patch (unless someone else chimes in with new information).Did anyone pick option 1)? If I understand correctly, we probably want to ensure that at least some bots do this, so we can ensure an old compiler + LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN build actually remains functional up until the point support for the old compiler is actually removed. Best, Alex