similar to: [LLVMdev] PR 8199 - Can we get patches reviewed?

On Thu, Dec 9, 2010 at 9:46 AM, Török Edwin <edwintorok at gmail.com> wrote: > On Thu, 09 Dec 2010 11:24:19 -0600 > greened at obbligato.org (David A. Greene) wrote: > >> greened at obbligato.org (David A. Greene) writes: >> >> > Often I run a few different builds in parallel, with different >> > obj/build directories.  Is it possible that the test

> -----Original Message----- > From: cfe-dev <cfe-dev-bounces at lists.llvm.org> On Behalf Of Renato Golin > via cfe-dev > Sent: Friday, October 11, 2019 11:24 AM > To: David Greene <dag at cray.com> > Cc: llvm-dev at lists.llvm.org; cfe-dev at lists.llvm.org; Gerolf Hoflehner > <ghoflehner at apple.com>; openmp-dev at lists.llvm.org; lldb-dev at

Renato Golin via cfe-dev <cfe-dev at lists.llvm.org> writes: > On Thu, 10 Oct 2019 at 22:26, David Greene <dag at cray.com> wrote: >> That would be a shame. Where is test-suite run right now? Are there >> bots? How are regressions reported? > > There is no shame in making the test-suite better. That's not what I meant, sorry. I mean it would be a shame

Yea at first I was worried that maybe I changed the semantics of how it looked in PATH, and you had clang-func-mapping in your PATH somewhere before but now lit was building a different PATH. But I looked at that change and it wasn't even creating that substitution before. So it looks like that CL is indeed the problem. On Fri, Sep 22, 2017 at 11:38 AM Vedant Kumar <vsk at apple.com>

Jason Kim <jasonwkim at google.com> writes: >>> There is definitely something to this.  If I take a random failing >>> testcase and run the test in isolation in the shell, it works.  So >>> what, if anything, does lit/FileCheck/etc. do that might run >>> interference if there is another copy of lit/FileCheck/etc. running >>> at the same time? I

Is there a way to do this with llvm-lit, i.e., use the equivalent of backticks? foo takes a single argument, but doesn't read from stdin. // RUN foo some_arg > %t; FileCheck %s < %t // RUN foo `cat %t` | FileCheck --check-prefix=INVERSE // CHECK: {{^[0-9]+$}} // INVERSE: some_arg thanks... don -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Thu, 09 Dec 2010 11:24:19 -0600 greened at obbligato.org (David A. Greene) wrote: > greened at obbligato.org (David A. Greene) writes: > > > Often I run a few different builds in parallel, with different > > obj/build directories. Is it possible that the test infrastructure > > writes something to the source directories or some common temp > > directory? That

Hi all, Not sure if there's a better forum for lit discussion, please advise. I'm experimenting with lit for IWYU testing. We're a little sensitive to relative vs absolute paths, especially when trying to determine the include-name for various headers. I've noticed lit always expands substitutions (e.g. %s) to absolute paths, and I'd like to be able to introduce substitutions

On Thu, Jan 17, 2013 at 1:19 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote: > On Wed, Jan 16, 2013 at 9:33 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote: >> On Wed, Jan 16, 2013 at 9:24 PM, Chris Lattner <clattner at apple.com> wrote: >>> >>> On Jan 16, 2013, at 10:32 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote: >>>

In the root llvm/CMakeLists.txt we have: if( ${PYTHON_VERSION_STRING} VERSION_LESS 2.7 ) message(FATAL_ERROR "Python 2.7 or newer is required") endif() But lit seems to still be stuck in a Python 2.5 world. For example, detectCPUs is redundant now that we have multiprocessing.cpu_count() (multiprocessing requires >=2.6). And there are a bunch of other Python 2.5 workarounds

On Thu, Jan 3, 2019 at 11:54 PM Kuba Mracek <mracek at apple.com> wrote: > > > > > On Jan 3, 2019, at 1:21 PM, David Greene via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > >> What you're seeing is just the fact that lit is waiting on > >>

Great! I'll circle around to this at some point. Despite the "obvious" nature of it I still am wary of underestimating the cruftiness of the buildbots, so I'll probably do it some time at night when the bots are mostly green so that I can easily see if any bots *are* broken by this. -- Sean Silva On Tue, Feb 23, 2016 at 6:55 PM, Chris Matthews <chris.matthews at

This sounds like a good idea to me! I can’t think of any common platform where you can’t get 2.7. Lets get rid of that legacy cruft! > On Feb 23, 2016, at 1:32 PM, Eric Christopher <echristo at gmail.com> wrote: > > Seems reasonable to me. Chris? > > On Mon, Feb 22, 2016, 8:40 PM Sean Silva via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at

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

> My understanding in the past is that we didn't officially support > using the llvm gold plugin with ld.bfd. We don't have any bots that > test that combination (which is why you see the code below in > lit.common.cfg). In my mind, that means using the llvm gold plugin > with ld.bfd is at your own risk (and therefore I would like to remove > the wording around using

Ok, that makes sense. I don't see this as a good enough argument to remove backslash support though. For problems like the clang_cc1 substitution mistakes, it would be much better to just improve the substitution support so that those cause immediate test failures. I would definitely support a move to make lit's substitution machinery more strict. For problems like your first search, I

> On Jul 7, 2017, at 2:19 PM, Reid Kleckner <rnk at google.com> wrote: > > On Fri, Jul 7, 2017 at 1:20 PM, George Karpenkov via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Thus, I propose modifying FileCheck default behavior to dump all swallowed output on stderr when the test has failed. > Would there be any objections to

Anything to remove the current duplication in test code between ExecutionEngine & ExecutionEngine/MCJIT is a step forward. While that mess is tidied up, we may as well factor in a solution to allow setting default JITs. IMO target support for MCJIT would improve faster if at some point the transition was made completely. It's going to happen eventually, and the sooner for those targets

So you're referring to llvm_test_prepare? There aren't many examples of that being used. I tried adding a call to it in my test directory's CMakeLists.txt like so: llvm_test_prepare(WORKDIR ${CMAKE_CURRENT_BINARY_DIR} export MY_VAR=42 ) In the hopes that something would happen, even an error, but it had no effect. Nothing at http://llvm.org/docs/lnt/tests.html explains how to

> On Sep 22, 2017, at 11:36 AM, Vedant Kumar <vsk at apple.com> wrote: > > Ah, the problem goes away once I build clang-func-mapping. > > I stripped some stuff out, but here's pretty much what clang/test/lit.cfg.py says my PATH is: > > ** PATH **: /Volumes/Builds/llvm.org-coverage-braces-RA/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin > > I wonder how