Take #2. Don't piggyback on the existing config.build_mode. Instead,
define a new lit feature for each build feature we need (currently
just "asserts"). Teach both autoconf'd and cmake'd Makefiles to define
this feature within test/lit.site.cfg. This doesn't require any lit
harness changes and should be more robust across build systems.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133664 91177308-0d34-0410-b5e6-96231b3b80d8
REQUIRES: Asserts
REQUIRES: Debug
This required chaining test configuration properties. It seems like a
generally good thing to do.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133131 91177308-0d34-0410-b5e6-96231b3b80d8
It broke the llvm-gcc-native-mingw32 buildbot, and we need all of them to be green for the 2.9 branch.
Takumi, please reapply after we branch, preferably with a fix ;-)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127107 91177308-0d34-0410-b5e6-96231b3b80d8
run the tests using DejaGNU, but not for much longer. This is a last call for
DejaGNU supporters, if no one complains soon the DejaGNU support is going to
die.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109997 91177308-0d34-0410-b5e6-96231b3b80d8
the llvm tests :-(
It was failing with
-- Testing: 5324 tests, 8 threads --
Fatal Python error: PyEval_AcquireThread: NULL new thread state
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105610 91177308-0d34-0410-b5e6-96231b3b80d8
--enable-shared configure flag to have the tools linked shared. (2.7svn is just
$(LLVMVersion) so it'll change to "2.7" in the release.) Always link the
example programs shared to test that the shared library keeps working.
On my mac laptop, Debug libLLVM2.7svn.dylib is 39MB, and opt (for example) is
16M static vs 440K shared.
Two things are less than ideal here:
1) The library doesn't include any version information. Since we expect to break
the ABI with every release, this shouldn't be much of a problem. If we do
release a compatible 2.7.1, we may be able to hack its library to work with
binaries compiled against 2.7.0, or we can just ask them to recompile. I'm
hoping to get a real packaging expert to look at this for the 2.8 release.
2) llvm-config doesn't yet have an option to print link options for the shared
library. I'll add this as a subsequent patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96559 91177308-0d34-0410-b5e6-96231b3b80d8
address space (though it only uses a small fraction of that), and the
buildbots disallow that.
Also add a comment to the Makefile's ulimit line warning future
developers that changing it won't work.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@88994 91177308-0d34-0410-b5e6-96231b3b80d8
The large code model is documented at
http://www.x86-64.org/documentation/abi.pdf and says that calls should
assume their target doesn't live within the 32-bit pc-relative offset
that fits in the call instruction.
To do this, we turn off the global-address->target-global-address
conversion in X86TargetLowering::LowerCall(). The first attempt at
this broke the lazy JIT because it can separate the movabs(imm->reg)
from the actual call instruction. The lazy JIT receives the address of
the movabs as a relocation and needs to record the return address from
the call; and then when that call happens, it needs to patch the
movabs with the newly-compiled target. We could thread the call
instruction into the relocation and record the movabs<->call mapping
explicitly, but that seems to require at least as much new
complication in the code generator as this change.
To fix this, we make lazy functions _always_ go through a call
stub. You'd think we'd only have to force lazy calls through a stub on
difficult platforms, but that turns out to break indirect calls
through a function pointer. The right fix for that is to distinguish
between calls and address-of operations on uncompiled functions, but
that's complex enough to leave for someone else to do.
Another attempt at this defined a new CALL64i pseudo-instruction,
which expanded to a 2-instruction sequence in the assembly output and
was special-cased in the X86CodeEmitter's emitInstruction()
function. That broke indirect calls in the same way as above.
This patch also removes a hack forcing Darwin to the small code model.
Without far-call-stubs, the small code model requires things of the
JITMemoryManager that the DefaultJITMemoryManager can't provide.
Thanks to echristo for lots of testing!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@88984 91177308-0d34-0410-b5e6-96231b3b80d8
Also, fix a few other details of the cmake test target and rename it to
'check'. CMake tests now work for the most part, but there are a handful of
failures left due to missing site.exp bits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86452 91177308-0d34-0410-b5e6-96231b3b80d8
There's a bug with ocamlc that uses "char*" instead of "const char*" for
global string variables. This causes g++ to be very noisy when linking
ocamlc programs. That's why the ocaml test used to cat to /dev/null.
ocamlopt doesn't have this problem, so we can get rid of the >/dev/null,
which may obscure some problems.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80968 91177308-0d34-0410-b5e6-96231b3b80d8
try to use i686-darwin to build for arm-eabi, you'll quickly run into
several false assumptions that the target OS must be the same as the
host OS. These patches split $(OS) into $(HOST_OS) and $(TARGET_OS) to
help builds like "make check" and the test-suite able to cross
compile. Along the way a target of *-unknown-eabi is defined as
"Freestanding" so that TARGET_OS checks have something to work with.
Patch by Sandeep Patel!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79296 91177308-0d34-0410-b5e6-96231b3b80d8
as 32-bit code by default, and if gcc defaults to 64-bit code then ocamlc
requires a -cc "gcc -arch i386" option. We were hardcoding -cc g++
and throwing away any other compiler options that were determined when
ocamlc was configured and built.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@76658 91177308-0d34-0410-b5e6-96231b3b80d8
test suite. Remove documentation for --with-f2c, which
is no longer supported. Remove information about obtaining
tcl/expect, which ship with Mac OS X by default since
10.4.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74271 91177308-0d34-0410-b5e6-96231b3b80d8
friends should work. This fixes 2006-11-30-Pubnames.cpp and friends on darwin
with the new -mmacosx-version-min change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@65564 91177308-0d34-0410-b5e6-96231b3b80d8
beware of the 42000 leaks reported by valgrind in the Constant.cpp + Type.cpp files. it needs fixing IMHO
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@57245 91177308-0d34-0410-b5e6-96231b3b80d8
(on solaris10, which are:
CodeGen/PowerPC/frounds.ll
Transforms/InstCombine/2008-02-23-MulSub.ll)
I needed a tool to figure out which one is the guilty.
To this end I have added a verbosity
option to the test/Makefile.
It can be invoked thus:
gmake check TESTSUITE=CodeGen/PowerPC VERBOSE="-v -v"
(The number of "-v"s specifies the verbosity level.
Instead of "-v" other aliases can be specified,
please consult the dejagnu docs for info.)
At level >= 2 following line is logged for each
test, before running it:
ABOUT TO RUN: <test>.ll
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@47602 91177308-0d34-0410-b5e6-96231b3b80d8
make check-one TESTONE=test/path/to/test.ll
This runs a single check in exactly the same way that dejagnu runs it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@36049 91177308-0d34-0410-b5e6-96231b3b80d8
that want to use LLVM's notion of compiling and linking programs. This
includes all the -I -L and optimization switches that LLVM would using to
compile or link any of this files.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@35920 91177308-0d34-0410-b5e6-96231b3b80d8
Prevent infinite loops and memory bombs by setting a ulimit on time and
space for running the dejagnu tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34184 91177308-0d34-0410-b5e6-96231b3b80d8
test directory to precede the test suite name. That is, it will strip off
test/ from TESTSUITE which allows path completion from the command line.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@31662 91177308-0d34-0410-b5e6-96231b3b80d8
committed). This infrastructure is only activated when RUNLLVM2CPP=1 is
specified on the make command line. Currently it is only supported in the
Feature test suite.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28525 91177308-0d34-0410-b5e6-96231b3b80d8
eliminated. This can happen, for example, if LLVM is configured without
llvm-gcc in which case things like LLVMGCC_VERSION will be empty. In
such cases, deja-gnu fails with:
can't read "llvmgcc_version": no such variable
because it sees:
set llvmgcc_version
instead of:
set llvmgcc_version ""
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@27676 91177308-0d34-0410-b5e6-96231b3b80d8
JIT can run against a multi-threaded program without getting its data
structures messed up. Also had to add the examples directory to the path
for the tests so that ParallelJIT can be found.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22415 91177308-0d34-0410-b5e6-96231b3b80d8
llvmgxx programs. dejagnu doesn't understand single quote and we need to
pass double quotes through to the shell in order to escape blanks in the
paths. This patch uses \" to escape the quotes passed through to the shell.
Thanks to Aaron Gray for testing this out on cygwin.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22155 91177308-0d34-0410-b5e6-96231b3b80d8
