search for: xfailed

Hello LLVM-Dev, The other day as I was digging through lldb’s test suite I noticed they support something kinda neat. In their python test harness, the attribute they use to denote expected failures supports a parameter for specifying the bug number. This got me thinking. I believe that any test that is marked XFAIL is a bug, and we can use LIT to enforce that. So I wrote a patch

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

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

On 28 September 2016 at 10:08, Chris Bieneman via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I cannot think of any situation where a universally failing test > should be in-tree unless it is a bug that someone is expecting to fix. It seems moderately common to mark something XFAIL temporarily to get the bots green while then going ahead to fix the issue. Your proposal would add

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

> > And in the test file there is a line: > > XFAIL: powerpc64, s390x, mips, sparc > > This is a crude attempt at "XFAIL: big-endian". The mips entry here is just > wrong if the system is little-endian - the test passes on little-endian machines > and fails on big-endian. This is obviously a problem. 'XFAIL: mips' counts as an XFAIL for all mips targets

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of > Krzysztof Parzyszek via llvm-dev > Sent: Monday, October 03, 2016 10:40 AM > To: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] [RFC] Require PRs for XFAILing tests > > On 10/3/2016 12:21 PM, Robinson, Paul via llvm-dev wrote: > > As David Blaikie mentioned,

If you can help get it working on big-endian systems, we should be able to remove the XFAIL. That seems like the cleanest way out of this. Yuchen sent a patch to llvm-commits on 12/19/13. (I can resend it to you if you don’t have that.) Can you try that out on a BE mips system? On Feb 21, 2014, at 7:11 AM, Reed Kotler <Reed.Kotler at imgtec.com> wrote: > On 02/21/2014 02:58 AM, Daniel

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

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

> -----Original Message----- > From: Alex Bradbury [mailto:asb at asbradbury.org] > Sent: Saturday, October 01, 2016 1:06 PM > To: Robinson, Paul > Cc: Renato Golin; Chris Bieneman; llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] [RFC] Require PRs for XFAILing tests > > On 28 September 2016 at 19:58, Robinson, Paul via llvm-dev > <llvm-dev at lists.llvm.org>

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

changeset: 11011:b60ea69932b1 tag: tip parent: 11010:e4f1519b473f parent: 10999:15304ad81c50 user: kfraser@localhost.localdomain date: Wed Aug 9 12:04:20 2006 +0100 summary: Merge with xenppc-unstable. Hardware: x460 NOTE: This runs were done with the latest version of Harry''s disk.iso patch. ******************** x86_32(no PAE):

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

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

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

The attached patch eliminates http://llvm.org/bugs/show_bug.cgi?id=15817 by removing the remaining "; XFAIL:*" added in http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130415/171812.html. The Isl/CodeGen/scevcodegen-1.ll testcase in polly appears as an XPASS in current llvm/polly 3.3 and trunk svn for both x86_64-apple-darwin* and x86_64 Fedora 15 when built against isl

changeset: 11278:8273f730371b tag: tip user: Ian Campbell <ian.campbell@xensource.com> date: Tue Aug 29 06:23:11 2006 +0100 summary: Fix definition of LINUX_VER so that doesn''t pickup LINUX_VER3 Hardware: x460 ******************** x86_32(no PAE): *************************** * dom0: SLES10 GM * dom0 boots fine * xend starts without problem --- Linux

Hi folks, The llvm-arm-linux buildbot, although old, is up and running and the only failures I can see were XFAIL, but still being run on ARM: http://lab.llvm.org:8011/builders/llvm-arm-linux/builds/2158 Any ideas why they're still being run on that buildbot? If we can clear those, we can get it passing again. cheers, --renato -------------- next part -------------- An HTML attachment was