similar to: [LLVMdev] Marking a test suite test XFAIL

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

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

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, >>

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've finished adding the -rundejagnu option to the nightly tester script, which was the last step to fully support Dejagnu. I think now is the appropriate time to discuss keeping QMTest or switching to Dejagnu. A lot of work went into using QMTest, so I think we should make this decision carefully and before the 1.4 release. Here are the pros and cons in my eyes, please feel free to add your

Tanya Lattner wrote: > I've finished adding the -rundejagnu option to the nightly tester script, > which was the last step to fully support Dejagnu. I think now is the > appropriate time to discuss keeping QMTest or switching to Dejagnu. A lot > of work went into using QMTest, so I think we should make this decision > carefully and before the 1.4 release. > > Here are the

Dale Johannesen wrote: > On Feb 6, 2009, at 8:52 PM, Patrick Simmons wrote: > > >> Hi, >> >> I'm trying to run the tests in llvm-suite, but I've run into trouble. >> First, I had the llvm-suite checkout in a directory alongside the llvm >> compiler checkout, but, when I ran "make" from llvm-suite, it >> complained >> about

Hi, I am currently trying to set up new performance and regression testers for Polly and LLVM and would like to XFAIL two test cases. I am using the LNTBuilder instead of the NightlyTestBuilder out of the assumption that the LNTBuilder is the more modern solution. However, when trying to xfail test cases I realized the xfail=[] parameter of getLNTFactor is ignored. Previously this was not an

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

On Sep 20, 2010, at 9:40 PMPDT, John Thompson wrote: > Thanks, Stuart. Sorry, I had some left-over editing cruft in my email. From Googling runtest, I had found dejagnu, which I'd heard some folks were using over there, so I used the local package manager to install it. But from what you said I went ahead and got the dejagnu sources and built it, but had problems in running make

Thanks, Stuart. Sorry, I had some left-over editing cruft in my email. >From Googling runtest, I had found dejagnu, which I'd heard some folks were using over there, so I used the local package manager to install it. But from what you said I went ahead and got the dejagnu sources and built it, but had problems in running make install, which is trying to put it /usr/local/bin rather than

Hi, I'm trying to run the tests in llvm-suite, but I've run into trouble. First, I had the llvm-suite checkout in a directory alongside the llvm compiler checkout, but, when I ran "make" from llvm-suite, it complained about there not being a Makefile two levels above it, so I moved llvm-suite into the "test" subdirectory inside the llvm compiler checkout. I ran

Patrick Simmons wrote: > Dale Johannesen wrote: >> On Feb 6, 2009, at 8:52 PM, Patrick Simmons wrote: >> >> >>> Hi, >>> >>> I'm trying to run the tests in llvm-suite, but I've run into trouble. >>> First, I had the llvm-suite checkout in a directory alongside the llvm >>> compiler checkout, but, when I ran "make"

On Feb 6, 2009, at 8:52 PM, Patrick Simmons wrote: > Hi, > > I'm trying to run the tests in llvm-suite, but I've run into trouble. > First, I had the llvm-suite checkout in a directory alongside the llvm > compiler checkout, but, when I ran "make" from llvm-suite, it > complained > about there not being a Makefile two levels above it, so I moved >

On Sunday 28 November 2004 00:24, Tanya Lattner wrote: Just some comments from a QMTest user... Note however, that even with them, dejagnu looks better. > Cons of QMTest: > 1) You have to use the gui to add directories. I think you're wrong. Manually creating a directory would work, as QMTest does not place anything special in directories. > 2) You have to use the gui to XFAIL

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

This may be an unpopular opinion (and I don’t have the full context on those specific issues), but I believe that these are an abuse of XFAIL, and should probably be written in terms of REQUIRES instead of XFAIL. I believe XFAIL tests actually execute, and are just marked as expected failure. If a test is not expected to ever succeed, we shouldn’t bother running it, which is what the REQUIRES

> On Sep 29, 2016, at 7:52 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Wed, Sep 28, 2016 at 11:58 AM Robinson, Paul via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > On 28 September 2016 at 10:08, Chris Bieneman via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>

Tanya Lattner wrote: > >> 1. I'm still looking for volunteers to test MacOS X and Solaris. >> If you'd like to volunteer, please email the list to let us know. > > > I'll do minimal testing on Sparc. I'm not going to look into any > regressions though since no one has been really watching Sparc since I > graduated and I am sure there are

On Jul 15, 2009, at 4:48 PMPDT, Daniel Dunbar wrote: > That depends on what you call a false positive. The public buildbot > regularly fails because of mailing Frontend tests, and I have had > continues failures of some DejaGNU tests for a long time on some > builders. Its not a false positive per se, but one starts to ignore > the failures because they aren't unexpected. Yes.