similar to: [RFC][FileCheck] New option to negate check patterns

​Hi all, > I feel it might be confusing to have a CHECK becomes effectively a CHECK-NOT, > especially if the RUN line is far from the CHECK line (which is often the case when > a single RUN line drives several groups of CHECK directives (e.g. code generation > tested for several functions for a specific feature, like PIC). You also loose control > on where the NOT should be:

Thanks for the suggestions. I think the naming the whole line idea is okay, but it feels a bit clunky. Either we'd have to have a syntax that FileCheck would recognise without caring about the prefix (which seems to be against the ethos of FileCheck, and also makes it less flexible), or in the case I'm referring to, we'd have to have an extra line that does nothing other than define

Before addressing the CHECK-NOT case, I’m still unclear about the DAG case. What should the first DAG line match? The regex matching would first attempt to match “10 12” but the expression evaluation would fail; so the DAG candidate wouldn’t match; does this mean the DAG matching does not continue searching, and the test fails? Or would we restart the search…. where? With “0 12” (skipping only

Any kind of variable definition on a CHECK-NOT line would seem like it would be asking for trouble. Do we allow text variable definitions on a NOT? False fails are better than false matches. Given that it will fail on a line where you'd expect a match, or possibly for the line to be skipped, it's a matter of refining the match expression, which is something that you have to do sometimes

Hi, I'm looking for some feedback on pain points people have with FileCheck in terms of missing features to help people interested in working on FileCheck to prioritize the work accordingly. I am personally interested in improving FileCheck on 2 issues whenever time permits it: * being able to test for consecutive lines in arbitrary order, i.e. something akin to CHECK-DAG blocks where

I ran into an LLVM/Clang crash when attempting to do the following: 1. Build Clang from the release/9.x branch source. 2. Use the Clang from (1) to build clangd on the release/9.x branch, with LLVM_ENABLE_MODULES=On. I wrote a script to reproduce the crash: https://gist.github.com/modocache/ac366ca9673b93bb21e75d3e72162608 At the above URL, you'll find a script `repro.sh` that reproduces

Hi, TL;DR: Is it ok to allow numeric variables used on same line as defined except for CHECK-NOT and with false negatives? FileCheck does not currently allow a numeric variable from being used on the same line they were defined. I have a tentative patch to add that support but it comes with caveats so before going through review I'd like to get consensus on whether those caveats are

Hi all, Many of our lit tests use FileCheck and a tool like llvm-readobj to check properties of a section header/symbol/etc. A typical (pseudoised for brevity) output to match against might be something like the following: Symbols [ Symbol { Name: foo Value: 0 Type: Function Section: .foo (1) } Symbol { Name: bar Value: 1 Type: Object Section: .foo (1) } ]

On 05/24/2018 08:46 AM, via llvm-dev wrote: > Background > ---------- > > FileCheck [0] is a cornerstone testing tool for the LLVM project. It > has grown new features over the years to meet new needs, but these > sometimes have surprising and counter-intuitive behavior [1]. This > has become even more evident in Joel Denny's recent quest to repair > what seemed like

Background ---------- FileCheck [0] is a cornerstone testing tool for the LLVM project. It has grown new features over the years to meet new needs, but these sometimes have surprising and counter-intuitive behavior [1]. This has become even more evident in Joel Denny's recent quest to repair what seemed like an obvious defect [2] but which led me to the conclusion [3] that FileCheck sorely

Hi Joel, That sounds like a very nice idea and definitely a direction I could get behind. However I feel that outside the use case I suggested, this functionality would only be used to compress CHECK lines that contain repeated text, not saying its a bad or good thing though. WDYT? ~Nathan On Fri, 2020-07-17 at 14:52 -0400, Joel E. Denny via cfe-dev wrote: > Hi Nathan, > > On Fri, Jul

A few replies, then I'll post a revised spec v2 which ought to incorporate all the other feedback. If I missed something, give a shout. Actually, I wish there were a way to do that [constrain DAG to a single line] for the sake of matching unordered text on a single line. SAME after DAGs is as close as I can get to that. Maybe we need a CHECK-DAG-SAME. Hmmm. You know, there were cases

Thanks Joel and Chris, comments inline. >> CHECK: Scans the search range for a pattern match. Fails if no match >> is found.  The end of the match range becomes the start of the search >> range for subsequent directives. >> >> CHECK-SAME: Like CHECK, plus there must be zero newlines prior to the >> start of the match range. > > ... within the search

Hi Paul, On Thu, May 24, 2018 at 9:46 AM, <paul.robinson at sony.com> wrote: > Background > ---------- > > FileCheck [0] is a cornerstone testing tool for the LLVM project. It > has grown new features over the years to meet new needs, but these > sometimes have surprising and counter-intuitive behavior [1]. This > has become even more evident in Joel Denny's

On Thu, Jan 17, 2013 at 8:36 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote: > We have to options: > (a) replace 'FileCheck' with '%FileCheck' in all tests, and teach > 'lit' to replace '%FileCheck' with 'FileCheck --dump-input-on-error'; > > (b) teach 'lit' to replace a plain 'FileCheck'. > > The first approach

Hi all: I'm writing testcase for the MC layer regression in llvm, the disassembled string is a bit complicate, for example: "IALU.T0 (I0) = BIU0.DM ; REPEAT AT ( 2 ) ;;" The spaces in the disassembled string is error-prone. Is there any option to tell the FileCheck utility to ignore the spaces ? Kind Regards. Shawn.

Graphcore is a well funded startup that is developing a new processor architecture for accelerating machine-learning applications. We are looking for talented engineers to build world-class development tools that fully exploit the computational capabilities of our architecture. Multiple roles are available - if you enjoy hacking on compilers, debuggers or linkers we would like to speak to you.

On Thu, Jan 17, 2013 at 7:51 PM, Sean Silva <silvas at purdue.edu> wrote: > On Thu, Jan 17, 2013 at 8:36 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote: >> We have to options: >> (a) replace 'FileCheck' with '%FileCheck' in all tests, and teach >> 'lit' to replace '%FileCheck' with 'FileCheck --dump-input-on-error';

Hello I have pass operating on bitcode file which produces more than one equivalent representation. opt --my-pass <%s | Filecheck %s --my-pass generates files a.rpt b.rpt c.rpt . How do i write test without writing all 3 files to stdin. I have considered CHECK-LABEL for each. it creates bulky checks. Thanks Mahesh -------------- next part -------------- An HTML attachment was

On Jan 16, 2013, at 10:32 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote: > Hello, > > When someone breaks a FileCheck-based test on some buildbot, sometimes > it may not be obvious *why* did it fail. If the failure can not be > reproduced locally, it can be very hard to fix. > > I propose adding a "very verbose" mode to FileCheck. In this mode >