Use the same environment when invoking llvm-config from lit.cfg as
will be used when running tests, so that ASAN_OPTIONS, INCLUDE, etc.
are present.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218403 91177308-0d34-0410-b5e6-96231b3b80d8
Approved by Jim Grosbach, Lang Hames, Rafael Espindola.
This reinstates commits r215111, 215115, 215116, 215117, 215136.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216982 91177308-0d34-0410-b5e6-96231b3b80d8
I've fixed most of the simple bugs and currently "check-llvm" test suite
has 26 failures, and "check-clang" suite has 5 failures.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216701 91177308-0d34-0410-b5e6-96231b3b80d8
be deleted. This will be reapplied as soon as possible and before
the 3.6 branch date at any rate.
Approved by Jim Grosbach, Lang Hames, Rafael Espindola.
This reverts commits r215111, 215115, 215116, 215117, 215136.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215154 91177308-0d34-0410-b5e6-96231b3b80d8
I am sure we will be finding bits and pieces of dead code for years to
come, but this is a good start.
Thanks to Lang Hames for making MCJIT a good replacement!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215111 91177308-0d34-0410-b5e6-96231b3b80d8
These are only used when the 'ld' in the path is gold and the plugin has
been built, but it is already a start to make sure we don't regress features
that cannot be tested with llvm-lto.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214058 91177308-0d34-0410-b5e6-96231b3b80d8
Ugh. Turns out not even transformation passes link in how to read IR.
I sincerely believe the buildbots will finally agree with my system
after this though. (I don't really understand why all of this has been
working on my system, but not on all the buildbots.)
Create a new tool called llvm-uselistorder to use for verifying use-list
order. For now, just dump everything from the (now defunct)
-verify-use-list-order pass into the tool.
This might be a better way to test use-list order anyway.
Part of PR5680.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213957 91177308-0d34-0410-b5e6-96231b3b80d8
A builder complained that it couldn't find llvm-vtabledump, this is
probably because it wasn't a dependency of the 'test' target.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213905 91177308-0d34-0410-b5e6-96231b3b80d8
This makes it *really* easy to debug leaks FYI:
ASAN_OPTIONS=detect_leaks=1 ./bin/llvm-lit -v <path to test>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207874 91177308-0d34-0410-b5e6-96231b3b80d8
More updating of tests to be explicit about the target triple rather than
relying on the default target triple supporting ARM mode.
Indicate to lit that object emission is not yet available for Windows on ARM.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205545 91177308-0d34-0410-b5e6-96231b3b80d8
This is a bit of a stab in the dark, since I have zlib on my machine.
Just going to bounce it off the bots & see if it sticks.
Do we have some convention for negative REQUIRES: checks? Or do I just
need to add a feature like I've done here?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205050 91177308-0d34-0410-b5e6-96231b3b80d8
Introducing llvm-profdata, a tool for merging profile data generated by
PGO instrumentation in clang.
- The name indicates a file extension of <name>.profdata. Eventually
profile data output by clang should be changed to that extension.
- llvm-profdata merges two profiles. However, the name is more general,
since it will likely pick up more tasks (such as summarizing a single
profile).
- llvm-profdata parses the current text-based format, but will be
updated once we settle on a binary format.
<rdar://problem/15949645>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201535 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-mcmarkup, obj2yaml and yaml2obj were missing from the substitutions list,
causing the test suite to fail in a sandboxed environment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193559 91177308-0d34-0410-b5e6-96231b3b80d8
I saw the case that 'native' was mis-enabled when x86_64-pc-win32 on x86_64-linux.
FIXME: Consider cases that target can be executed even if host_triple were different from target_triple.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193459 91177308-0d34-0410-b5e6-96231b3b80d8
This provides rudimentary testing of the llvm-c api.
The following commands are implemented:
* --module-dump
Read bytecode from stdin - print ir
* --module-list-functions
Read bytecode from stdin - list summary of functions
* --module-list-globals
Read bytecode from stdin - list summary of globals
* --targets-list
List available targets
* --object-list-sections
Read object file from stdin - list sections
* --object-list-symbols
Read object file from stdin - list symbols (like nm)
* --disassemble
Read lines of triple, hex ascii machine code from stdin - print disassembly
* --calc
Read lines of name, rpn from stdin - print generated module ir
Differential-Revision: http://llvm-reviews.chandlerc.com/D1776
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193233 91177308-0d34-0410-b5e6-96231b3b80d8
infrastructure.
This was essentially work toward PGO based on a design that had several
flaws, partially dating from a time when LLVM had a different
architecture, and with an effort to modernize it abandoned without being
completed. Since then, it has bitrotted for several years further. The
result is nearly unusable, and isn't helping any of the modern PGO
efforts. Instead, it is getting in the way, adding confusion about PGO
in LLVM and distracting everyone with maintenance on essentially dead
code. Removing it paves the way for modern efforts around PGO.
Among other effects, this removes the last of the runtime libraries from
LLVM. Those are being developed in the separate 'compiler-rt' project
now, with somewhat different licensing specifically more approriate for
runtimes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191835 91177308-0d34-0410-b5e6-96231b3b80d8
line just to add or remove a single element. What I wouldn't give to
have clang-format here an be able to format this more densely without
caring...
Re-group and sort the entries while here to make the whole thing more
clear.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191828 91177308-0d34-0410-b5e6-96231b3b80d8
- Instead of setting the suffixes in a bunch of places, just set one master
list in the top-level config. We now only modify the suffix list in a few
suites that have one particular unique suffix (.ml, .mc, .yaml, .td, .py).
- Aside from removing the need for a bunch of lit.local.cfg files, this enables
4 tests that were inadvertently being skipped (one in
Transforms/BranchFolding, a .s file each in DebugInfo/AArch64 and
CodeGen/PowerPC, and one in CodeGen/SI which is now failing and has been
XFAILED).
- This commit also fixes a bunch of config files to use config.root instead of
older copy-pasted code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188513 91177308-0d34-0410-b5e6-96231b3b80d8
Note that this will require a recent version of the linker for Darwin
builds with LTO to pass these tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187711 91177308-0d34-0410-b5e6-96231b3b80d8
Archive files (.a) can have a symbol table indicating which object
files in them define which symbols. The purpose of this symbol table
is to speed up linking by allowing the linker the read only the .o
files it is actually going to use instead of having to parse every
object's symbol table.
LLVM's archive library currently supports a LLVM specific format for
such table. It is hard to see any value in that now that llvm-ld is
gone:
* System linkers don't use it: GNU ar uses the same plugin as the
linker to create archive files with a regular index. The OS X ar
creates no symbol table for IL files, I assume the linker just parses
all IL files.
* It doesn't interact well with archives having both IL and native objects.
* We probably don't want to be responsible for yet another archive
format variant.
This patch then:
* Removes support for creating and reading such index from lib/Archive.
* Remove llvm-ranlib, since there is nothing left for it to do.
We should in the future add support for regular indexes to llvm-ar for
both native and IL objects. When we do that, llvm-ranlib should be
reimplemented as a symlink to llvm-ar, as it is equivalent to "ar s".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184019 91177308-0d34-0410-b5e6-96231b3b80d8
(-llc), similarly to the way it was done for clang and llvmc.
This doesn't affect the upstream llvm tests but helps when developing custom
LLVM-based tools and testing them within the LLVM regression framework.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183994 91177308-0d34-0410-b5e6-96231b3b80d8
