similar to: [LLVMdev] How to XFAIL JIT tests for AArch64

Kostya, Christophe, I'm running the full tests on AARch64 and the only RT test that fails is: UndefinedBehaviorSanitizer-Standalone :: TestCases/Float/cast-overflow.cpp The problem seems to be a trap in __sanitizer::internal_memchr() while trying to handle __ubsan::__ubsan_handle_float_cast_overflow(). I haven't looked at it in detail, has anyone seen this? Is UBSan meant to run on

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

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

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

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 Tanya, Bill, Anton and Martin. I have recently set-up and installed a ARM buildbot that have currently been building since August 21. You can follow its progress here http://google1.osuosl.org:8011/builders/llvm-arm-linux I have also started to investigate the test failures and writing bugreports. Currently about all test failures except are related to the ExecutionEngine JIT and i am doing

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

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

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

Hi all, I am seeing a number of JIT unit test failures on AArch64. Some googling returns past discussions (circa 2014) but as far as I can tell, everything should be working. I listed the failures below. These are from a Release build. A Debug build does not exhibit the failures. I built with gcc 6.1.0 on SuSE 12. Switching to gcc 8.2.0 also makes the problem go away, both in Debug and

Hi David, I don't have access to a gcc 6.1.0 / aarch64 setup, but I've tried the tests locally and they're passing asan/ubsan/tsan clean, and there is no obvious uninitialized memory use in the test case (though who knows where it might be inlined from in a release build). When you say other tests broke with 8.2.0, do you mean other ORC tests specifically, or just other LLVM tests?

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

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

Lang Hames via llvm-dev <llvm-dev at lists.llvm.org> writes: > I am afraid nothing leaps to mind. Once you have a chance to look at > them again please let me know -- I'd be happy to look at backtraces / > failures. Huh. Now the problem has disappeared. A colleague updated to ToT and now I'm not seeing the failures, even with gcc 6.1.0 in Release mode. Most

Just a quick note to say that I saw this. I'm tracking down what looks like another issue which may be undefined behavior within a PassManager test. That's more critical for us at the moment so I'm going to diagnose and send a report about that before getting back to the JIT tests. In the meantime, if Lang knows anything, that would be helpful. -David

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