Indeed this has finally stuck, with just clang-with-lto-ubuntu broken at the moment. I’m inclined to leave it checked in, and try to get it into the LLVM 8 branch as well.> On Feb 7, 2019, at 9:18 AM, paul.robinson at sony.com wrote: > > It seems the CMake changes have landed; but the docs are still a bit out of date? > CMake.html talks about LLVM_FORCE_USE_OLD_TOOLCHAIN but not LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN.I’m. Not sure how one updates the website’s docs, I had assumed the RST files would automatically get rebuilt and pushed? Agreed we want it fixed, but I don’t think it’s good reason to revert since the error message is pretty clear.> Also, it looks like LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN is not propagated down to the NATIVE configuration when you set LLVM_OPTIMIZED_TABLEGEN. If that's going to be a permanent deficiency, it should be mentioned in the docs as well.Someone mentioned MSVC was having issues that way? https://reviews.llvm.org/rL353374#624722 <https://reviews.llvm.org/rL353374#624722> That seems like general badness in the way that configuration is set up, no? It should probably get fixed separately.> Thanks, > --paulr > <> > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of JF Bastien via llvm-dev > Sent: Saturday, February 02, 2019 1:04 AM > To: via llvm-dev > Subject: Re: [llvm-dev] [RFC] migrating past C++11 > > After a few attempts I think we’re in sight of success: we only have the two following bots remaining with old versions of libstdc++ and new versions of clang: > > polly-amd64-linux > polly-arm-linux > > Once fixed the toolchain bump should stick. > > > On Jan 31, 2019, at 2:07 PM, JF Bastien via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > > On Jan 31, 2019, at 2:03 PM, Alex Bradbury <asb at asbradbury.org <mailto:asb at asbradbury.org>> wrote: > > On Tue, 29 Jan 2019 at 21:05, JF Bastien via llvm-dev > <llvm-dev at lists.llvm.org <mailto: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). > > 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. > > Reid asked me to do so for sanitizer-windows: > https://reviews.llvm.org/D57525 <https://reviews.llvm.org/D57525> > > Ideally yes we’d have bots covering all eventualities, but this is but one of many holes in our coverage. On the upside, that hole is disappearing in a few months :) > > > > Best, > > Alex > > _______________________________________________ > 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/20190207/2be24bec/attachment-0001.html>
It seems the CMake changes have landed; but the docs are still a bit out of date? CMake.html talks about LLVM_FORCE_USE_OLD_TOOLCHAIN but not LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN. I’m. Not sure how one updates the website’s docs, I had assumed the RST files would automatically get rebuilt and pushed? Agreed we want it fixed, but I don’t think it’s good reason to revert since the error message is pretty clear. Huh. I also thought the website was kept up to date automagically, which is why I looked at the website not the source; but the source does have the new option. Never mind… Also, it looks like LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN is not propagated down to the NATIVE configuration when you set LLVM_OPTIMIZED_TABLEGEN. If that's going to be a permanent deficiency, it should be mentioned in the docs as well. Someone mentioned MSVC was having issues that way? https://reviews.llvm.org/rL353374#624722 That seems like general badness in the way that configuration is set up, no? It should probably get fixed separately "Somebody else ought to get around to fixing that someday so why bother documenting something that might eventually change" does not seem like a very robust argument. I've answered a pile of questions from newcomers lately, I would prefer that people not add new reasons for the documentation to lie about how things work currently. Or more accurately, don't work, because you can't currently use both those options at once. If someone does change how the optimized-tablegen feature works (or eliminates it entirely), surely they would be able to update the documentation accordingly? So, please fix. --paulr -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190207/fecd3157/attachment.html>
> On Feb 7, 2019, at 11:01 AM, paul.robinson at sony.com wrote: > > It seems the CMake changes have landed; but the docs are still a bit out of date? > CMake.html talks about LLVM_FORCE_USE_OLD_TOOLCHAIN but not LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN. > > I’m. Not sure how one updates the website’s docs, I had assumed the RST files would automatically get rebuilt and pushed? Agreed we want it fixed, but I don’t think it’s good reason to revert since the error message is pretty clear. > > Huh. I also thought the website was kept up to date automagically, which is why I looked at the website not the source; but the source does have the new option. Never mind… <> > > Also, it looks like LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN is not propagated down to the NATIVE configuration when you set LLVM_OPTIMIZED_TABLEGEN. If that's going to be a permanent deficiency, it should be mentioned in the docs as well. > > Someone mentioned MSVC was having issues that way? https://reviews.llvm.org/rL353374#624722 <https://reviews.llvm.org/rL353374#624722> > That seems like general badness in the way that configuration is set up, no? It should probably get fixed separately > > "Somebody else ought to get around to fixing that someday so why bother documenting something that might eventually change" does not seem like a very robust argument. I've answered a pile of questions from newcomers lately, I would prefer that people not add new reasons for the documentation to lie about how things work currently. Or more accurately, don't work, because you can't currently use both those options at once. > > If someone does change how the optimized-tablegen feature works (or eliminates it entirely), surely they would be able to update the documentation accordingly? > So, please fix.Can you clarify what you’re asking for exactly, and who you’re asking it from? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190207/d81e7495/attachment.html>
Hooray! Thanks for perservering! On Thu, Feb 7, 2019, 1:28 PM JF Bastien via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Indeed this has finally stuck, with just clang-with-lto-ubuntu broken at > the moment. I’m inclined to leave it checked in, and try to get it into the > LLVM 8 branch as well. > > > On Feb 7, 2019, at 9:18 AM, paul.robinson at sony.com wrote: > > It seems the CMake changes have landed; but the docs are still a bit out > of date? > CMake.html talks about LLVM_FORCE_USE_OLD_TOOLCHAIN but not > LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN. > > > I’m. Not sure how one updates the website’s docs, I had assumed the RST > files would automatically get rebuilt and pushed? Agreed we want it fixed, > but I don’t think it’s good reason to revert since the error message is > pretty clear. > > > Also, it looks like LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN is not propagated > down to the NATIVE configuration when you set LLVM_OPTIMIZED_TABLEGEN. If > that's going to be a permanent deficiency, it should be mentioned in the > docs as well. > > > Someone mentioned MSVC was having issues that way? > https://reviews.llvm.org/rL353374#624722 > That seems like general badness in the way that configuration is set up, > no? It should probably get fixed separately. > > > Thanks, > --paulr > > *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org > <llvm-dev-bounces at lists.llvm.org>] *On Behalf Of *JF Bastien via llvm-dev > *Sent:* Saturday, February 02, 2019 1:04 AM > *To:* via llvm-dev > *Subject:* Re: [llvm-dev] [RFC] migrating past C++11 > > After a few attempts I think we’re in sight of success: we only have the > two following bots remaining with old versions of libstdc++ and new > versions of clang: > > > polly-amd64-linux > polly-arm-linux > > > Once fixed the toolchain bump should stick. > > > On Jan 31, 2019, at 2:07 PM, JF Bastien via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > > On Jan 31, 2019, at 2:03 PM, Alex Bradbury <asb at asbradbury.org> wrote: > > 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. > > Reid asked me to do so for sanitizer-windows: > > https://reviews.llvm.org/D57525 > > > Ideally yes we’d have bots covering all eventualities, but this is but one > of many holes in our coverage. On the upside, that hole is disappearing in > a few months :) > > > > Best, > > Alex > > _______________________________________________ > 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/20190207/72c106f9/attachment.html>
On Thu, Feb 7, 2019 at 7:28 PM JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> wrote:> Indeed this has finally stuck, with just clang-with-lto-ubuntu broken at the moment. I’m inclined to leave it checked in, and try to get it into the LLVM 8 branch as well.It's been merged to the branch in r353512, so this will be part of the release. Please let me know if there are any issues or follow-ups that are relevant for the branch.
Please make sure r353463 is in the release too. Thanks. James On Fri, 8 Feb 2019 at 11:10, Hans Wennborg via llvm-dev < llvm-dev at lists.llvm.org> wrote:> On Thu, Feb 7, 2019 at 7:28 PM JF Bastien via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Indeed this has finally stuck, with just clang-with-lto-ubuntu broken at > the moment. I’m inclined to leave it checked in, and try to get it into the > LLVM 8 branch as well. > > It's been merged to the branch in r353512, so this will be part of the > release. Please let me know if there are any issues or follow-ups that > are relevant for the branch. > _______________________________________________ > 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/20190208/0d4696b9/attachment.html>