Platform-specific RUN lines in lit tests?

[David Blaikie]

On Wed, May 14, 2014 at 11:54 AM, Timur Iskhodzhanov
<timurrrr at google.com> wrote:
>
>
>
> 2014-05-14 21:00 GMT+04:00 David Blaikie <dblaikie at gmail.com>:
>
>> On Wed, May 14, 2014 at 9:43 AM, Timur Iskhodzhanov <timurrrr at google.com>
>> wrote:
>> > Hi,
>> >
>> > I'm currently enabling ASan lit tests on Windows.
>> >
>> > One problem I have is that some tests use multiple RUN lines, some of
>> > which
>> > are cross-platform and others are platform- or compiler-specific.
>> > Is there any magic method to make some of the RUN lines conditional for
>> > a
>> > specific OS?
>> >
>> > I think one of the goals here is to have as many tests that are actually
>> > shared on all the platforms and thus I don't think it's a very good idea
>> > to
>> > e.g. duplicate tests and have platform-specific RUN lines in them.
>> >
>> > Examples to consider are:
>> > [all located in projects/compiler/rt/test/asan/TestCases/]
>> >
>> > 1) sanity_check_pure_c.c has the following run lines:
>> > // RUN: %clang_asan -O2 %s -o %t
>> > // RUN: not %run %t 2>&1 | FileCheck %s
>> > // RUN: %clang_asan -O2 %s -pie -fPIE -o %t
>> > // RUN: not %run %t 2>&1 | FileCheck %s
>> >
>> > The first two lines are ok to run on any OS.
>> > The third run line uses "-pie -fPIE" which doesn't apply on Windows.
>> > Is there any way to disable the third and fourth RUN lines on Windows
>> > only?
>> >
>> > 2) print-stack-trace.cc has the following run lines:
>> > // RUN: %clangxx_asan -O0 %s -o %t && %run %t 2>&1 | FileCheck %s
>> > // RUN: %clangxx_asan -O3 %s -o %t && %run %t 2>&1 | FileCheck %s
>> >
>> > The test expectations assume a particular stack trace being printed.
>> > However, on Windows -O3 enables tail call / inlining optimizations that
>> > do
>> > not allow us to completely restore the stack trace from debug
>> > information
>> > (yet?).
>> >
>> > 3) interface_test.cc has the following run lines:
>> > // RUN: %clang_asan %s -o %t && %run %t
>> > // RUN: %clang_asan -x c %s -o %t && %run %t
>> > // RUN: %clang %s -o %t && %run %t
>> > // RUN: %clang -x c %s -o %t && %run %t
>> >
>> > the first and third are ok, the second and the fourth assume clang has
>> > "-x
>> > c" available, which is not true on Windows where we use the clang-cl
>> > driver.
>> > The equivalent CL/clang-cl option is "/TC".
>> > Options are:
>> > - Copy the test to interface_test.c
>>
>> You don't need to copy the whole test - you can just write another
>> file (interface_test_windows.test, or whatever) that, in its RUN line,
>> references interface_test.c (you might have to move interface_test.c
>> into an "Inputs" directory, then you would have interface.test and
>> interface_windows.test that both reference the .c file in Inputs) -
>> and one of those .test files would have the REQUIRES: blah and have
>> the RUN lines that aren't portable in it.
>
>
> Hm, interesting!  But somewhat hack-ish :(

Somewhat. I think we already have a few instances of this in the
codebase, but I wouldn't be opposed to making them more streamlined
potentially. (with things like the RUN-<feature> syntax suggested,
potentially)

- Dave

>
>>
>> > - Use a macro for "-x c" / "/TC"  (sounds like an overkill for just one
>> > test?)
>>
>> This seems like an annoying thing to deal with - is it particularly
>> useful to test the clang-cl driver rather than just using the normal
>> clang gcc-like driver?
>
>
> Currently we have to use clang-cl as the default compiler to build tests
> since we fall back on a few TUs (most notably gtest).
>
> Also, I'd argue that a significant (prevailing?) portion of the ASan users
> on Windows will use clang-cl driver, so we want it to have the first-class
> support and test coverage.
>
>>
>> > - Conditional RUN line
>> > ...
>> >
>> > 4) no_asan_gen_globals.c
>> > // RUN: %clang_asan %s -o %t.exe
>> > // RUN: nm %t.exe | FileCheck %s
>> > -> Could probably use llvm-something.exe instead.
>> >
>> > -----
>> >
>> > Given that there's just a handful of problematic lit tests, I kinda
>> > think we
>> > can actually duplicate the tests a little, but I'd like to avoid that if
>> > possible.
>> >
>> > Any tips?
>> >
>> > --
>> > Tim
>> >
>> > _______________________________________________
>> > llvm-commits mailing list
>> > llvm-commits at cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>> >
>
>