[llvm-dev] [RFC] migrating past C++11
Krzysztof Parzyszek via llvm-dev
llvm-dev at lists.llvm.org
Thu Jan 31 06:27:26 PST 2019
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
>
More information about the llvm-dev
mailing list