it doesn't modify the exit code or the stdout contents, and so that it
doesn't clutter the output with "Command has output on stderr!".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110171 91177308-0d34-0410-b5e6-96231b3b80d8
integrated-test formats (sh and tcl style). The particular features which get
recognized are up to the test suite itself to define.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109062 91177308-0d34-0410-b5e6-96231b3b80d8
of runs without leak checking. We add -vg to the triple for non-checked runs,
or -vg_leak for checked runs. Also use this to XFAIL the TableGen tests, since
tablegen leaks like a sieve. This includes some valgrindArgs refactoring.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99103 91177308-0d34-0410-b5e6-96231b3b80d8
under valgrind:
==19577== Invalid free() / delete / delete[]
==19577== at 0x4C9C866: free (vg_replace_malloc.c:325)
==19577== by 0x5121104: ??? (in /lib/libc-2.10.2.so)
==19577== by 0x4C97412: _vgnU_freeres (vg_preloaded.c:62)
==19577== by 0x5041486: __run_exit_handlers (exit.c:93)
==19577== by 0x50414FE: exit (exit.c:100)
==19577== by 0x5028B5C: (below main) (libc-start.c:254)
==19577== Address 0xffffffff is not stack'd, malloc'd or (recently) free'd
==19577==
Apparently this happens under certain versions of glibc, so valgrind provides
the --run-libc-freeres=no option to avoid calling freeres(). This may increase
the number of "still reachable" blocks valgrind reports, but we don't care
about those, while this error breaks the buildbots.
There are upstream bugs about this at
http://sourceware.org/bugzilla/show_bug.cgi?id=10610 and
http://bugs.kde.org/show_bug.cgi?id=167483, but they don't look likely to be
fixed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98813 91177308-0d34-0410-b5e6-96231b3b80d8
IF(condition(value)):
If the value satisfies the condition, the line is processed by lit; otherwise
it is skipped. A test with no unignored directives is resolved as Unsupported.
The test suite is responsible for defining conditions; conditions are unary
functions over strings. I've defined two conditions in the LLVM test suite,
TARGET (with values like those in TARGETS_TO_BUILD) and BINDING (with values
like those in llvm_bindings). So for example you can write:
IF(BINDING(ocaml)): RUN: %blah %s -o -
and the RUN line will only execute if LLVM was configured with the ocaml
bindings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97726 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
- Used for running a single fixed command on a directory of files, with the
option of deriving a temporary input file from the test source.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@88844 91177308-0d34-0410-b5e6-96231b3b80d8
- Currently just useful for timing, although it could be extended as one (bad) way to deal with flaky tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@88827 91177308-0d34-0410-b5e6-96231b3b80d8
