similar to: [LLVMdev] QEMU testing for LIT execution tests

So I started prototyping remote testing for libcxx over the weekend: https://github.com/jroelofs/libcxx/tree/remote_test The SSHExecutor isn't quite finished yet, but this should give an idea of what I've got in mind. Does this look generic enough to work for other projects under the llvm-umbrella (LNT, test-suite, compiler_rt, libcxxabi, etc)? Are there use cases that you see

On 22 August 2014 01:48, Jim Grosbach <grosbach at apple.com> wrote: > No specific comments at the moment, but I do want to say that I very much believe this is worth pursuing. Better testing infrastructure for remote targets will be an absolutely fantastic improvement. Thank you and Dan both for pushing forward on the topic. +1 I remember Greg (cc'd) did some of that in

On 9/8/14, 12:39 PM, Greg Fitzgerald wrote: > Hi Jon, > > Compiler-rt, libcxx, libcxxabi should all use the same > cross-compilation testing strategy. Compiler-rt already has a working > solution. If it is inadequate for libcxx or libcxxabi, can we start > by addressing those deficiencies? One issue to start with is that none of the libcxx/libcxxabi tests have RUN lines. All

On 9/8/14, 3:31 PM, Greg Fitzgerald wrote: > Jon, > >> One issue to start with is that none of the libcxx/libcxxabi tests have RUN lines. > > Sorry, I didn't mean to imply that 'RUN:' lines should be added to > libcxx tests. It's fine that every one is implicitly: > > // RUN: %clang %s -o %t && %run %t > ... and then when an explicit

It is $target dependent. I’m curious what makes you think it is $host dependent. Thanks, Taewook On 3/3/17, 5:10 PM, "Jonathan Roelofs" <jonathan at codesourcery.com> wrote: On 3/3/17 12:23 PM, Taewook Oh wrote: > Thanks Jon. Actually I tried “x86_64-linux”, but it makes the test “Unsupported” from my linux machine, and it was because my test is under

I'm not sure that test have ever been run through LIT. It was tested on Android, but I don't have LIT tweaked for libc++abi the same way I do for libc++, so it was built outside of LIT and run manually. On Oct 27, 2014 11:41 AM, "Jonathan Roelofs" <jonathan at codesourcery.com> wrote: > > > On 10/27/14 11:39 AM, Renato Golin wrote: > > Right now, there's

On 18 December 2014 at 21:32, Jonathan Roelofs <jonathan at codesourcery.com> wrote: > I think this will help one facet of your problem: > http://reviews.llvm.org/D6584 I don't think so, because the tests don't time out, it's a buffering issue... --renato

Hi folks, I've updated the configuration for my libcxx buildbot (r220701) to pass some additional flags to compilation, including setting the CPU (so it won't need to use soft divide) and link flags + compiler-rt dependency to lit (so it won't fail with __aeabi_* symbols missing). Most problems should be all fixed once we reload the configuration in the build master. Right now,

Thanks Jon. Actually I tried “x86_64-linux”, but it makes the test “Unsupported” from my linux machine, and it was because my test is under clang, not llvm. It seems that clang doesn’t support “x86_64-linux” yet. Thanks again! Best, Taewook On 3/3/17, 10:57 AM, "Jonathan Roelofs" <jonathan at codesourcery.com> wrote: On 3/3/17 11:46 AM, Taewook Oh via llvm-dev

Folks, Some of our CMake buildbots are failing to timeout, and I believe it's something to do with how the output comes from the LIT tests, even though we add -v to LIT_ARGS. When the "check-all" stage runs, the output stops at the "Running tests" message and only prints the rest of the output (including all tests that pass, fail, etc) at the end. I believe this has to

Hi all, Is there any way to cross-compile LLVM and run check-all, or just the llvm-lit tests, (after moving the build directory) on the target machine? As far as I can tell from the CMakefiles, there's support only for cross-compiling LLVM and not for running the tests with the resulting compiler. Thanks, Vasileios

Hi, Me and my supervisor are interested in improving llvm's lit a little bit. Currently, there are few things, that seem to be not very convenient about the tool: * Having several RUN commands in a failing test, it's impossible to figure out, which of them actually caused the test to fail. We can output the number of the failing RUN line. * It would be nice to

What are all the different ways people run lit? I'm doing some refactoring and want to make sure I have all the based covered. Obviously you can use check-llvm. And you can also run llvm-lit.py in your bin directory and point it to your source tree. What else? Both of the aforementioned methods require running cmake first, is there any use case where someone runs lit without having run

Hello, I wonder if I can write a test that runs only on Linux. I was thinking of adding “REQUIRES” to the test, but couldn’t find a feature name for Linux (if one exists). Thanks! Best, Taewook -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170303/807b40ac/attachment-0001.html>

Folks, I'm trying to set up a libc++ buildbot on ARM and I found an inconsistency which I'm not sure how to fix. I got a build error like this: libc++abi.so: undefined reference to `_Unwind_GetGR' Since I expected that the symbol would be provided by that library, I searched the CMake on libc++abi and found this: option(LIBCXXABI_USE_LLVM_UNWINDER "Build and use the LLVM

Hi, > Cool, I hope this succeeds. I tried implementing per-test timeouts before, and couldn't get it to work in all cases. The review eventually fizzled out, and I abandoned it. > > Here's that old review: http://reviews.llvm.org/D6584 Perhaps you can cannibalize testcases from it. Thanks for that. I'll take a look. > >> >> I'm e-mailing llvm-dev rather

Hi, A feature I've wanted in lit for a while is a having a timeout per test. Attached are patches that implement this idea. I'm e-mailing llvm-dev rather than llvm-commits because I want to gather more feedback on my initial implementation and hopefully some answers to some unresolved issues with my implementation. Currently in lit you can set a global timeout for all of the tests but

On Jan 30, 2015, at 12:43 PM, Jonathan Roelofs <jonathan at codesourcery.com> wrote: > It would be nice if we had some libunwind-specific tests too. Currently we have none, other than the c++ abi tests. Nick, does Apple have any they're willing to upstream? Here is what Apple has: http://opensource.apple.com/source/libunwind/libunwind-35.3/testsuite/ If you think these are

On 14 August 2014 11:26, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > So you don't want to send it to the standard output. The things that want to parse it expect a file in the filesystem. So if you want the verbose build to be sticking it in a well-known file then I don't have strong objections, but it seems to be conflating two things. We run lit in -q mode in

+jyknight, who added --match-full-lines On 12/14/16 5:37 AM, Tom de Vries wrote: > Hi, > > this patch fixes a problem with leading/trailing whitespace matching > for FileCheck --strict-whitespace --match-full-lines. > > The resulting regexp string is '^bla3$' instead of '^ bla3$'. > > The patch fixes this, and makes the behavior match the documentation.