[llvm-dev] [RFC] migrating past C++11 (original) (raw)

Galina Kistanova via llvm-dev llvm-dev at lists.llvm.org
Thu Jan 31 10:43:55 PST 2019

Hello Krzysztof,

The bot description comes from your bot, that's what in the info/host file. Please update the description of those bots to avoid any confusions.

Thanks

Galina

On Thu, Jan 31, 2019 at 6:27 AM Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org> wrote:

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 > LLVMTEMPORARILYALLOWOLDTOOLCHAIN). 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 LLVMTEMPORARILYALLOWOLDTOOLCHAIN 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/compilersupport> 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#Latestversions >>> * GCC https://gcc.gnu.org/releases.html >>> * MSVC >>> https://en.wikipedia.org/wiki/MicrosoftVisualStudio 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/UsingCXXinMozillacode_ _>). >>> 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/compilersupport >>> * 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?utmmedium=email&utmsource=link&utmcampaign=sig-email&utmcontent=emailclient> > Virus-free. www.avg.com > <_ _http://www.avg.com/email-signature?utmmedium=email&utmsource=link&utmcampaign=sig-email&utmcontent=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 >

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/20190131/19961db8/attachment-0001.html>

More information about the llvm-dev mailing list