similar to: [LLVMdev] How to XFAIL test cases with buildbot LNTFactory

On 3 January 2013 21:53, David Blaikie <dblaikie at gmail.com> wrote: > That's how you achieve this goal. What a buildbot does is governed by > the configuration in the zorg repository (that's where we keep the > buildbot configuration code that is sync'd up to the lab.llvm.org > buildmaster). > Hi David, I had a go at Zorg after the website was back online. As

On Mon, Apr 22, 2013 at 10:56 AM, Renato Golin <renato.golin at linaro.org>wrote: > On 22 April 2013 18:02, Daniel Dunbar <daniel at zuster.org> wrote: > >> Ok, so we are already downloading from a private server (lab.llvm.org), >> which IMHO we should be doing because we want tight control over the >> dependencies etc. >> > > Agreed. > > >

On 3 January 2013 21:29, David Blaikie <dblaikie at gmail.com> wrote: > Fair enough - you could write up a patch for the zorg repository to do > this. > Wouldn't requiring every buildbot to use LNT achieve the same thing? --renato -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Thu, Jan 3, 2013 at 1:52 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 3 January 2013 21:29, David Blaikie <dblaikie at gmail.com> wrote: >> >> Fair enough - you could write up a patch for the zorg repository to do >> this. > > > Wouldn't requiring every buildbot to use LNT achieve the same thing? That's how you achieve this goal.

On 22 April 2013 18:02, Daniel Dunbar <daniel at zuster.org> wrote: > Ok, so we are already downloading from a private server (lab.llvm.org), > which IMHO we should be doing because we want tight control over the > dependencies etc. > Agreed. I forgot that your machine is outside the lab, so that may be involved > here. I don't fully understand the networking setup but

Hi Renato, On 07/01/13 11:45, Renato Golin wrote: > On 3 January 2013 21:53, David Blaikie <dblaikie at gmail.com > <mailto:dblaikie at gmail.com>> wrote: > > That's how you achieve this goal. What a buildbot does is governed by > the configuration in the zorg repository (that's where we keep the > buildbot configuration code that is sync'd up

On Mon, Apr 22, 2013 at 8:00 AM, Renato Golin <renato.golin at linaro.org>wrote: > Ping? > > This is getting as often as every other run... Is that process downloading > from an internal server? If not, should we? If yes, should we not? > Ok, so we are already downloading from a private server (lab.llvm.org), which IMHO we should be doing because we want tight control over

Chandler Carruth <chandlerc at gmail.com> wrote: > I've been working to revive the PPC64 build bots, and succeeded, but > not for the right reasons. There were still bootstrap assertion > failures and other pretty blatant errors. Then we figured out why: > the Clang bootstrapping build bots for Power7 are not actually > running any of the Clang tests! > > Could one

Hey Galina, Will; I've been working to revive the PPC64 build bots, and succeeded, but not for the right reasons. There were still bootstrap assertion failures and other pretty blatant errors. Then we figured out why: the Clang bootstrapping build bots for Power7 are not actually running any of the Clang tests! Could one of you tweak this build bot's configuration to match the other

On Jul 22, 2010, at 2:44 PMPDT, Patrick Alexander Simmons wrote: > From http://llvm.org/docs/TestingGuide.html > > Some tests are known to fail. Some are bugs that we have not fixed > yet; > others are features that we haven't added yet (or may never add). In > DejaGNU, the result for such tests will be XFAIL (eXpected FAILure). > In > this way, you can tell the

On Jul 25, 2010, at 2:37 AMPDT, Patrick Simmons wrote: > Thanks, Dale, that really helps. > > What about disabling only one backend of a specific test? > > Thanks, > --Patrick Not sure I understand, the test for Sparc in the example Makefile would appear to do that. You'll need to figure out a way to test for whatever condition you want to look at. There are lots of

I'm sorry; I should have been more clear. I mean, for instance, run a test but only with, say, llc, not with lli or cbackend. Thanks, --Patrick Dale Johannesen wrote: > > On Jul 25, 2010, at 2:37 AMPDT, Patrick Simmons wrote: > >> Thanks, Dale, that really helps. >> >> What about disabling only one backend of a specific test? >> >> Thanks, >>

Hi all, I'm investigating the following test case that reports as an unexpected pass on powerpc64-unknown-linux-gnu. Clang : CodeGenCXX/member-alignment.cpp This test case is marked as XFAIL for arm and powerpc. However, the test passes fine for powerpc64-unknown-linux-gnu. There are two tests of this form: void t::bar(void) { // CHECK: _ZN1t3barEv{{.*}} align 2

I'm looking at porting some tests to use multiple address spaces and have already found cases where the optimizations just don't handle it correctly, how do I mark them as XFAIL and with a prefix? The test in question is Other/constant-fold-gep.ll Micah -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Kostya, Alex, Some changes in the sanitizers made this test start passing: TestCases/Posix/start-deactivated.cc http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/4277 It passes on both ARM and Thumb, both NEON and non-NEON. Should we mark is as PASS now? Or is that a fluke? cheers, --renato

Hi, Currently, no tests that use lli without "-force-interpreter" are expected to pass when executing on an AArch64 model. However, they will pass if built and run on (say) X86, just setting the default target triple. So XFAIL gets unexpected passes on a compiler merely targetting AArch64 and leaving the tests as they are gives unexpected failures when they're run on a model. Does

Thanks, Dale, that really helps. What about disabling only one backend of a specific test? Thanks, --Patrick On 07/22/10 16:04, Dale Johannesen wrote: > > On Jul 22, 2010, at 2:44 PMPDT, Patrick Alexander Simmons wrote: > >> From http://llvm.org/docs/TestingGuide.html >> >> Some tests are known to fail. Some are bugs that we have not fixed yet; >> others are

From http://llvm.org/docs/TestingGuide.html Some tests are known to fail. Some are bugs that we have not fixed yet; others are features that we haven't added yet (or may never add). In DejaGNU, the result for such tests will be XFAIL (eXpected FAILure). In this way, you can tell the difference between an expected and unexpected failure. The tests in the test suite have no such feature at