[cfe-commits] [PATCH] move a non portable test to FileCheck

Chandler Carruth chandlerc at google.com
Tue May 1 00:59:32 PDT 2012


On Tue, May 1, 2012 at 12:19 AM, Jonathan Gray <jsg at jsg.id.au> wrote:

> On Mon, Apr 30, 2012 at 07:04:46PM -0700, Douglas Gregor wrote:
> >
> > On Apr 30, 2012, at 7:02 PM, Chandler Carruth <chandlerc at google.com>
> wrote:
> >
> > > On Mon, Apr 30, 2012 at 6:43 PM, Douglas Gregor <dgregor at apple.com>
> wrote:
> > >
> > > On Mar 21, 2012, at 3:07 AM, Jonathan Gray <jsg at jsg.id.au> wrote:
> > >
> > > > In test/Driver/clang-g-opts.c with tests of the form
> > > >
> > > > // RUN: %clang -S -v -o %t %s        2>&1 | not grep -w -- -g
> > > >
> > > > using 'not' here isn't portable and doesn't work on at least
> > > > OpenBSD and likely other systems (bash builtin?).
> > > >
> > > > patch to move this to FileCheck attached
> > >
> > > Committed as r155874, thanks!
> > >
> > > See my comments on the commit, I don't think this is a correct patch.
> > >
> > > Move-over, 'not' *is* portable, as we build the 'not' command out of
> the LLVM tree?
> > >
> > > I fully support moving it to filecheck, but the reason as stated
> doesn't comute for me.
> >
> > And? I completely misread the patch. Reverted in r155878.
> >
> >       - Doug
>
> I don't follow why this was reverted, could someone explain the reasoning?
>
> Before the diff the test fails when it shouldn't have.
>

I've not dug into the issue you're seeing or this specific tests, but there
were two abstract issues with the patch as proposed:

1) FileCheck asserts *all* of the checks on each run. There are several
distinct runs in the test, and only one of the assertions applied to each
run. FileCheck supports this use case, but you must use
--check-prefix(sp?). Look for that flag in the test suite. The patch as
proposed caused test suite failures for most build bots as a consequence.

2) I don't understand the claim that 'not' is unportable. We build our own
'not' binary out of the LLVM source code. It is not expected to be
installed on the system. What is the actual failure you are seeing? It is
more likely a functional failure than anything to do with the 'not' binary.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120501/75df79f2/attachment.html>


More information about the cfe-commits mailing list