Sorry I haven't had the time to dig into the issue but it looks someone else already fixed it :)
On Thu, 3 Dec 2020 at 21:00, David Blaikie dblaikie@gmail.com wrote:
This'll hopefully be addressed by https://reviews.llvm.org/D92563
On Mon, Nov 30, 2020 at 6:28 AM Diana Picus diana.picus@linaro.org wrote:
Ping again. We're seeing this on several aarch64 bots, what can we do about it?
On Mon, 23 Nov 2020 at 21:19, David Blaikie via llvm-dev llvm-dev@lists.llvm.org wrote:
Ping on this - Dan, any chance you could take a look here?
On Mon, Nov 9, 2020 at 1:48 PM Arthur Eubanks aeubanks@google.com wrote:
Another case: http://lab.llvm.org:8011/#/builders/43/builds/810 shtest-timeout.py seems to be fairly flaky on the clang-cmake-aarch64-quick bot: http://lab.llvm.org:8011/#/builders/43, I get notifications from it fairly often
On Thu, Oct 22, 2020 at 7:15 PM David Blaikie via llvm-dev llvm-dev@lists.llvm.org wrote:
Looks like there might still be some issues with the timeout tests? http://lab.llvm.org:8011/#/builders/126/builds/226/steps/13/logs/FAIL__lit__...
On Sun, Oct 4, 2020 at 2:44 PM Dan Liew dan@su-root.co.uk wrote:
> > One thing we could do to remove fragility in the test is to remove the > > running of `short.py` in the test. This is only invoked to check that > > it's possible for a command to run to completion in the presence of a > > fixed timeout. If we can live without testing that part (i.e. we only > > test that a timeout can be reached) then the test should be much more > > robust. > > If you're on board with that, it's a tradeoff I think is probably > reasonable from a test coverage V reliability V development time > tradeoff.
Sorry for the delay here. I've put a patch up for review that goes with this approach: https://reviews.llvm.org/D88807
LLVM Developers mailing list llvm-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
LLVM Developers mailing list llvm-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev