similar to: lit improvement

FWIW, I've seen it fail on some of my commits too, but I don't remember whether it was on the PS4 bot exclusively or not. Anyway, my understanding is that this test shouldn't inherently have different behaviour on PS4 specifically, but I could be mistaken. I suspect it's something more general to do with the configuration of the bot. James On 20 July 2018 at 03:52, Justin Bogner

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

Should "lit :: shtest-format.py" (from check-lit) be marked unsupported on PS4? It seems flakey there. This evening, it failed on my commit, r337514, and I'm fairly confident it wasn't my commit's fault. Then it recovered on the next commit. http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/33502

Dear all, Recently I've considering using LIT for my benchmark testing framework, and the only reference for LLVM-LIT is the man page and some READMEs. I don't find any documentations on config, which seems to be quite important to the tool. If I use lit outside LLVM source tree and use on my own test files, LIT marks them as 'unresolved'. So are there any documentations I can

On Sat, Jul 8, 2017 at 10:07 AM Daniel Dunbar <daniel_dunbar at apple.com> wrote: > > > On Jul 8, 2017, at 7:32 AM, David Blaikie <dblaikie at gmail.com> wrote: > > Ideally/the better integration with Buildbot would be to have these > outputs referenced as "associated files" (it's been a while since I played > with buildbot - I remember finding this

Rafael, Filipe, I am looking at the fixes you apply to sanitizer tests and they worry me. (e.g. https://reviews.llvm.org/D31498) The fixes are mostly mechanical and thus every single change looks safe, but given the amount of changes there is large risk to cripple some of the tests in a way that they will stop detecting failures. When I write a test for new functionality, I always verify that

Sorry, I was thinking to review the test but didn't. Is this test complete? It does invoke lld, but it didn't verify its output. On Mon, Jul 30, 2018 at 2:03 PM Andrew Kelley <superjoe30 at gmail.com> wrote: > Ping Rui. Is there anything else that needs to be done on this patch? > > On Tue, Jul 17, 2018 at 6:58 AM, Carlo Kok via llvm-dev < > llvm-dev at

On Tue, Jul 10, 2018 at 10:12 PM Carlo Kok via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > That sounds quite reasaonable; how does one usually go about doing that? a repro zip that hits both asserts? > You can take inspiration from anything in lld/test, but basically either an assembly source (or multiple) passed through llvm-mc and then lld, or a YAML file passed to yaml2obj

Got it. Attached are both the testcase & the fix. On Tue, Jul 17, 2018, at 12:06, Carlo Kok via llvm-dev wrote: > On Wed, Jul 11, 2018, at 16:45, Davide Italiano wrote: > > On Tue, Jul 10, 2018 at 10:12 PM Carlo Kok via llvm-dev > > <llvm-dev at lists.llvm.org> wrote: > > > > > > That sounds quite reasaonable; how does one usually go about doing that?

Hi David, Unfortunately writing a reliable test is tricky given that the functionality we're trying to test involves timing. I would advise against disabling the test entirely because it actually tests functionality that people use. I'd suggest bumping up the time limits. This is what I've done in the past. See commit 6dfcc78364fa3e8104d6e6634733863eb0bf4be8 Author: Dan Liew <dan

> On May 31, 2017, at 4:06 AM, Pavel Labath <labath at google.com> wrote: > > Thank you all for the pointers. I am going to look at these to see if > there is anything that we could reuse, and come back. In the mean > time, I'll reply to Mathiass's comments: > > On 26 May 2017 at 19:11, Matthias Braun <mbraun at apple.com> wrote: >>> Based on a

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, while experimenting with llvmlinux on Debian/testing AMD64 I wanted to run some x86-64 ASM tests. I fell over [1] and wanted to run it. So, I cloned clang from Git... $ git clone https://github.com/llvm-mirror/clang.git I looked through some docs where I have seen I need "llvm-lit" or "lit.py". The Debian package llvm-7-tools from <apt.llvm.org> does ship

On Wed, 16 Sep 2020 at 22:24, David Blaikie <dblaikie at gmail.com> wrote: > > I appreciate the value of the feature - but it's possible the test > doesn't pull its weight. Is the code that implements the feature > liable to failure/often touched? If it's pretty static/failure is > unlikely, possibly the time and flaky failures aren't worth the value > of

The simplest way to run a clang test case that I know of is to clone both llvm and clang repos, run all the tests, then run an individual test. IIRC like so: git clone llvm ...... cd llvm/tools git clone clang ..... cd ../../ mkdir build cd build cmake ../llvm ninja check-clang ./bin/llvm-lit -v ./tools/clang/test/Sema/asm.c On Sun, May 6, 2018 at 7:10 AM, Sedat Dilek via llvm-dev <

First, surely the right place for this discussion is the cfe-dev mailing list? Second, have you determined that this is a noticeable amount of time when compiling? I have no idea - in my Pascal compiler, parsing the code is ~0.1%, codegen to IR ~1.9% and LLVM 98%. But I'm sure Clang is more complex in many ways, so the proportion is probably a bit different - a measurement of the time spent

Hi all, I've got https://reviews.llvm.org/D37756 up for review currently which simplifies a lot of the logic in our lit config files. For most people, this will be completely transparent and "just work", but it breaks one workflow that people should be aware of. Problem: If you run lit by putting llvm-config in your path and then running <source-root>/utils/lit/lit.py

As of r313998, this workflow no longer works: cd <build-dir> ./bin/llvm-lit <src>/llvm/tools/clang/test/CoverageMapping I get: llvm-lit: /Users/vk/src/llvm.org-coverage-braces/llvm/tools/clang/test/lit.cfg.py:97: note: using clang: '/Volumes/Builds/llvm.org-coverage-braces-RA/bin/clang' llvm-lit:

Looking, thanks for the report. On Fri, Sep 22, 2017 at 11:22 AM Vedant Kumar <vsk at apple.com> wrote: > As of r313998, this workflow no longer works: > > cd <build-dir> > ./bin/llvm-lit <src>/llvm/tools/clang/test/CoverageMapping > > I get: > > llvm-lit: /Users/vk/src/llvm.org-coverage-braces/llvm/tools/clang/test/ > lit.cfg.py:97: note: using

llvm-lit is already put into <output-tree>/bin by CMake. There is a CMake target called `llvm-lit` that will generate the <output-dir>/bin/llvm-lit script. If you built only a few specific llvm targets such as FileCheck, etc then you may need to run this lit target manually. If you just run "ninja" for example, or "ninja check-llvm", it's automatically