[llvm-dev] [RFC] migrating past C++11
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
> > 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
> >
>
> _______________________________________________
> 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