search for: xfailing

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, our bug hygiene is not really that good. > > Adding a process to create more PRs is not going to change that. Of course not. The point of my remark is that linking an XFAIL test...

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

...e: RUN lines are basically sequences of commands that are put into a bash script and executed. Here is an example: RUN: llvm-as < %s | llvm-dis | llvm-as) Pros of Dejagnu: 1) Adding a test is very quick and easy. In most cases it requires just adding a RUN line to the file. No gui needed. 2) XFAILing a test is also quick and easy. You just add a XFAIL line to a single test with a * for all platforms, or specify part of a target triplet to match. No gui needed. 3) Because you add the RUN and XFAIL lines to each individual test, it's all located in one file. This makes it very easy under...

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> wrote: > > 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 u...

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

...s of commands that are put into a > bash script and executed. Here is an example: RUN: llvm-as < %s | llvm-dis > | llvm-as) > > Pros of Dejagnu: > 1) Adding a test is very quick and easy. In most cases it requires > just adding a RUN line to the file. No gui needed. > 2) XFAILing a test is also quick and easy. You just add a XFAIL > line to a single test with a * for all platforms, or specify part > of a target triplet to match. No gui needed. > 3) Because you add the RUN and XFAIL lines to each individual > test, it's all located in one file. This makes...

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