By adding a default config.excludes pattern we can avoid individual
suppressions in subdirectories.
This matches LLVM's lit.cfg which also excludes a few other common non-test
filenames for consistency.
llvm-svn: 194814
When running the tests under Cygwin using non-Cygwin python,
the platform would be Windows and there would be bash on the path,
so this check for MSYS would not work correctly.
llvm-svn: 187737
and add a new option --driver-mode= to control it explicitly.
The CCCIsCXX and CCCIsCPP flags were non-overlapping, i.e. there
are currently really three modes that Clang can run in: gcc, g++
or cpp, so it makes sense to represent them as an enum.
Having a command line flag to control it helps testing.
llvm-svn: 186605
This will allow for longer running FileCheck based tests to be committed to
clang for use on buildbots, preventing the normal make-check cycle from
increasing in time significantly.
This is a necessary change in order to commit the end-to-end arm neon intrinsic
tests since FileCheck takes ~20 seconds to run said test due to the large amount
of neon intrinsics.
To force a test to run only when --param run_long_tests=true is passed in use
the following requires statement:
// REQUIRES: long_tests
llvm-svn: 184385
We currently emit an error message when you try to use thread local
storage on targets that don't support it and testing C++11 thread
locals will trip this. We don't want to xfail the test for all darwin
hosts so add a quick hack to check for darwin10 and disable the
test based on that. Only checking darwin10 because anything earlier
is really old and I don't have a list of what other hosts don't
support tls handy.
Alternate suggestions welcome!
llvm-svn: 179671
The behavior can be overridden by setting LIT_USE_INTERNAL_SHELL=0 in
the environment.
This fixes issues with /dev/null for me and brings the test suite time
down to 30s. =D
llvm-svn: 179283
The stat cache became essentially useless ever since we started
validating all file entries in the PCH.
But the motivating reason for removing it now is that it also affected
correctness in this situation:
-You have a header without include guards (using "#pragma once" or #import)
-When creating the PCH:
-The same header is referenced in an #include with different filename cases.
-In the PCH, of course, we record only one file entry for the header file
-But we cache in the PCH file the stat info for both filename cases
-Then the source files are updated and the header file is updated in a way that
its size and modification time are the same but its inode changes
-When using the PCH:
-We validate the headers, we check that header file and we create a file entry with its current inode
-There's another #include with a filename with different case than the previously created file entry
-In order to get its stat info we go through the cached stat info of the PCH and we receive the old inode
-because of the different inodes, we think they are different files so we go ahead and include its contents.
Removing the stat cache will potentially break clients that are attempting to use the stat cache
as a way of avoiding having the actual input files available. If that use case is important, patches are welcome
to bring it back in a way that will actually work correctly (i.e., emit a PCH that is self-contained, coping with
literal strings, line/column computations, etc.).
This fixes rdar://5502805
llvm-svn: 167172
we had the -ccc-clang-cxx and -ccc-no-clang-cxx options to force them
on or off for testing.
Clang c++ support is now production quality and these options are dead.
llvm-svn: 166986
The implementation also includes a Relax NG schema and tests for the schema
itself. The schema is used in c-index-test to verify that XML documents we
produce are valid. In order to do the validation, we add an optional libxml2
dependency for c-index-test.
Credits for CMake part go to Doug Gregor. Credits for Autoconf part go to Eric
Christopher. Thanks!
llvm-svn: 161431
When creating the MCSubtargetInfo, the assembler driver uses the CPU and
feature string to construct a more accurate model of what instructions
are and are not legal.
rdar://10840476
llvm-svn: 150273
We don't actually need a separate flag for non-sysrooted paths as the
driver has to manage the sysroot anyways. The driver is not infrequently
adding paths to the header search based on their existence on the
filesystem. For that, it has to add the sysroot anyways, we should pass
it on down to CC1 already joined. More importantly, the driver cannot in
all cases distinguish between sysrooted paths and paths that are
relative to the Clang binary's installation directory. Essentially, we
always need to ignore the system root for these internal header search
options. It turns out in most of the places we were already providing
the system root in the driver, and then another one in CC1 so this fixes
several bugs.
llvm-svn: 143917
rather than presuming that it is 3.0. This is extra important as the
version should be 3.1, but CMake hasn't caught up with the times.
That'll be fixed in a separate commit.
llvm-svn: 143823
is a pretty gross hack, but I don't have any significantly cleaner ideas
for this. There are several things obviously gross about it:
1) Lit shouldn't know that Clang needs this. This really that bad, as
Lit already knows about CC1 and other internal details.
2) This hard codes the '3.0' version number, which is pretty lame.
3) This hard codes every other aspect of the resource dir structure
which is less lame than the version number, but still not great.
However, it should bring the MSVC tests back to life, and it should
unblock the rest of the move from Frontend to Driver, so I think it's
worth a bit of grossness that is isolated in our testing infrastructure
while we figure out the best long term approach. I have the following
ideas, some of which only solve part of the problem (and thus might need
to be combined with other ideas):
a) Create a symlink or other convenience path instead of a version
number.
b) Run 'clang' directly in the lit.cfg, look at its resource dir, and use
that.
c) Switch all the tests to use the driver instead of CC1.
d) Hack the frontend to synthesize builtin include directories when none
are provided by the driver.
I don't like (d) because it feels very hackish and likely to break. We
can only solve a small part of the problem with (a). I wanted to vote
for (c), but lots of the tests in this bucket are really heavily using
internal-only flags like -verify and -triple. I'm loath to complicate
them with the full driver layer. Also, switching them to the driver adds
more than just builtin headers, but all of the rest of the system
headers!
This leaves me with (b). If others like (b), I'll switch to it, but it
felt a bit icky. Nothing concrete, and the other options look
significantly worse, but I felt icky enough that I wanted to start with
a more brain-dead patch to stop the bleeding, and gauge others' feelings
here.
llvm-svn: 143804
These tests have been failing since the beginning of buildbot time:
crash-recovery-code-complete.c
crash-recovery-reparse.c
crash-recovery.c
llvm-svn: 138672
Alp Toker