similar to: [LLVMdev] FileCheck supports regex's

On Thu, Jan 17, 2013 at 10:20 AM, Jim Grosbach <grosbach at apple.com> wrote: > > On Jan 17, 2013, at 9:57 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote: > >> 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

On Thu, Jan 17, 2013 at 1:30 PM, Eli Bendersky <eliben at google.com> wrote: > This is unfortunate. Last month I tweaked TestingGuide.rst to > discourage grep in favor of FileCheck. It now says: > > "The recommended way to examine output to figure out if the test > passes it using the FileCheck tool. The usage of grep in RUN lines is > discouraged." > >

On Jan 17, 2013, at 10:30 AM, Eli Bendersky <eliben at google.com> wrote: > On Thu, Jan 17, 2013 at 10:20 AM, Jim Grosbach <grosbach at apple.com> wrote: >> >> On Jan 17, 2013, at 9:57 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote: >> >>> On Thu, Jan 17, 2013 at 7:51 PM, Sean Silva <silvas at purdue.edu> wrote: >>>> On Thu,

On Thu, Jan 17, 2013 at 10:32 AM, Jim Grosbach <grosbach at apple.com> wrote: > > On Jan 17, 2013, at 10:30 AM, Eli Bendersky <eliben at google.com> wrote: > >> On Thu, Jan 17, 2013 at 10:20 AM, Jim Grosbach <grosbach at apple.com> wrote: >>> >>> On Jan 17, 2013, at 9:57 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote: >>>

On Jan 17, 2013, at 9:57 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote: > 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

Alright, I guess it isn’t just my pain then, it makes it feel better ☺ I think that proposed feature would be really nice, since it would encourage people to write tests that have a //CHECK: some-thing-after-header first! From: Reid Kleckner [mailto:rnk at google.com] Sent: Thursday, March 30, 2017 11:15 AM To: Keane, Erich <erich.keane at intel.com> Cc: llvm-dev at lists.llvm.org Subject:

Hi all, quite a few tests use the pattern "2>&1 | FileCheck %s". AFAIK how stdout and stderr are merged into a single character stream is undefined and depends e.g. on whether stdout is buffered. I think we are often saved by the fact that standard output is written only at the end of the program and stderr is unbuffered, i.e. always written before stdout. A lot of tests disable

Hi all- I hope this is the right place for this. Anyway, the primary usage for the utility "FileCheck" is to pattern match for specific values in a stream. This is perfectly consistent and deterministic for the most part! However, when validating clang's LLVM-IR generation, it is possible to make an invalid match against the top few generated lines (the LLVM-IR Headers), which are

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

Hello, I was wondering about extending FileCheck to enable creating line anchors. These are numeric variables that hold the value of the line number that where they were defined. The motivation for this comes from test cases using clang-based diagnostics which often include notes attached to source locations in different parts of the file. In order to test for the correct location of the note,

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

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

On Thu, Jan 17, 2013 at 1:23 AM, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote: > 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 1:19 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote: >> I agree that a command line option would be better. But in that case >> all tests should be updated. It is not an issue for me -- it is >> mostly mechanical. So should I change tests to use %FileCheck? > > Here's a third attempt. Thanks in advance for driving this forward.

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 >

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: >> >>> Hello, >>> >>> When someone breaks a FileCheck-based test on some buildbot,

On Thu, Jan 17, 2013 at 8:43 AM, Chris Lattner <clattner at apple.com> wrote: > On Jan 16, 2013, at 1:19 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote: >>> I agree that a command line option would be better. But in that case >>> all tests should be updated. It is not an issue for me -- it is >>> mostly mechanical. So should I change tests to use

On Thu, Jan 17, 2013 at 3:31 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote: > On Thu, Jan 17, 2013 at 1:23 AM, Evgeniy Stepanov > <eugeni.stepanov at gmail.com> wrote: >> 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:

Hi Changcheng, Below is an example took from test/CodeGen/X86/add.ll: define i32 @test1(i32 inreg %a) nounwind { %b = add i32 %a, 128 ret i32 %b ; X32: subl $-128, %eax ; X64: subl $-128, } 1. The first step, you write a function by using LLVM IR. define i32 @test1(i32 inreg %a) nounwind { %b = add i32 %a, 128 ret i32 %b } This will be left to LLVM toolchain to generate

Hi, thanks for your letter,but i have read it several times,and now i am confused still.because i do not know how the test work. for a simple sample: ; RUN: llvm-as < %s | llvm-dis | FileCheck %s @addr = external global i64 define i64 @add_unsigned(i64 %x, i64 %y) { ; CHECK: %z = add nuw i64 %x, %y %z = add nuw i64 %x, %y ret i64 %z } 1.FileCheck verify the file that llvm-dis output and