similar to: [LLVMdev] XFAIL ASAN on ARM

On 8 October 2014 12:38, Evgeniy Stepanov <eugenis at google.com> wrote: > When running the final binary. Same thing... :( Should I bisect where that got broken? Do you have any way of testing that locally? This is just a basic CMake build on ARM, nothing special. "ninja check-asan". cheers, --renato

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

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

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

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

Hi, Sorry to bother, but I checked around and did not succed creating a bundle from six existing packages (which are checkable, installable, etc. individually). I carefully followed the procedure given in ch. 1.1.5 Package bundles. However, I am getting hoffmann at fluke:~/R/Sources >R CMD check cwhmisc * checking for working latex ... OK * using log directory

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, sorry for this lengthy post. I am using R-2.0.0 on Unix, compiled. Overview: A) R CMD check: Unaccounted top-level text B) In which sections of *.Rd is LaTeX notation allowed, where *not*? C) Codoc mismatches and polyvalent parameters D) Successful R CMD INSTALL and R CMD build E) cp ../Rd.sty . is copy necessary? F) latex ./CWHstat-manual.tex runs into trouble When running >R CMD

Hi, sorry for this lengthy post. I am using R-2.0.0 on Unix, compiled. Overview: A) R CMD check: Unaccounted top-level text B) In which sections of *.Rd is LaTeX notation allowed, where *not*? C) Codoc mismatches and polyvalent parameters D) Successful R CMD INSTALL and R CMD build E) cp ../Rd.sty . is copy necessary? F) latex ./CWHstat-manual.tex runs into trouble When running >R CMD

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

Folks, As of this run: http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/746 There are three classes of failures that need fixing before we get the bot green: 1. AddressSanitizer.BuiltinLongJmpTest Unit Test Two configurations fail: * Asan-arm-inline-Test * Asan-arm-with-calls-Test I wonder what's the best way to run it individually and reduce the error. I'm not

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

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

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

We have users who have their desktop folders on a Samba share. Some of them have been getting "Delayed Write Failure" messages recently on the "cookies/index.dat" file. At first I thought it was a fluke related to a network outage we experienced, but now I'm finding out it had been happening previously. This is Samba 2.2.5 on SuSE Linux SLES7 on S/390. Does anyone have

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

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