ocamlc and ocamlopt expose a distinct set of buildsystem bugs, e.g.
only ocamlc would detect -custom or -dllib-related bugs, and as all
buildbots will have ocamlopt, these bugs will stay hidden.

This change should add no more than 30 seconds of testing time.

llvm-svn: 221137

llvm-svn: 220919

llvm-svn: 220900

This commit updates the OCaml bindings and tests to use ocamlfind.
The bindings are migrated in order to use ctypes, which are now
required for MCJIT-backed Llvm_executionengine.
The tests are migrated in order to use OUnit and to verify that
the distributed META.llvm allows to build working executables.

Every OCaml toolchain invocation is now chained through ocamlfind,
which (in theory) allows to cross-compile the OCaml bindings.

The configure script now checks for ctypes (>= 0.2.3) and
OUnit (>= 2). The code depending on these libraries will be added
later. The configure script does not check the package versions
in order to keep changes less invasive.

Additionally, OCaml bindings will now be automatically enabled
if ocamlfind is detected on the system, rather than ocamlc, as it
was before.

llvm-svn: 220899

Previously, tests hardcoded ocamlopt and cmxa, which broke builds on
machines without ocamlopt. Instead, they now fall back to ocamlc.

As a side effect this fixes PR14727, which was caused by a crude hack
that replaced gcc with g++ everywhere in the ocamlopt native compiler
path and passes it back using -cc. Now the tests use the same
technique as META, i.e. -cclib -lstdc++. It might be more fragile
than using g++ explicitly, but it will break when the installed
package will also break, which is good.

llvm-svn: 220828

This tool lets us build LLVM components within the tree by setting up a
$GOPATH that resembles a tree fetched in the normal way with "go get".

It is intended that components such as the Go frontend will be built in-tree
using this tool.

Differential Revision: http://reviews.llvm.org/D5902

llvm-svn: 220462

This code is based on the existing LLVM Go bindings project hosted at:
https://github.com/go-llvm/llvm

Note that all contributors to the gollvm project have agreed to relicense
their changes under the LLVM license and submit them to the LLVM project.

Differential Revision: http://reviews.llvm.org/D5684

llvm-svn: 219976

llvm/test/lit.cfg: Suppress dwarf stuff for targeting x86_64-mingw32 while investigating since r219108.

llvm-svn: 219171

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.

llvm-svn: 218403

llvm-svn: 217979

Approved by Jim Grosbach, Lang Hames, Rafael Espindola.

This reinstates commits r215111, 215115, 215116, 215117, 215136.

llvm-svn: 216982

I've fixed most of the simple bugs and currently "check-llvm" test suite
has 26 failures, and "check-clang" suite has 5 failures.

llvm-svn: 216701

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.

llvm-svn: 215154

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!

llvm-svn: 215111

llvm-svn: 214318

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.

llvm-svn: 214058

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.

llvm-svn: 213957

A builder complained that it couldn't find llvm-vtabledump, this is
probably because it wasn't a dependency of the 'test' target.

llvm-svn: 213905

llvm-svn: 213839

llvm-svn: 212819

It is unused and it looks like it was never used.

llvm-svn: 211508

.debug_frame is not emitted for targeting Windows x64.

llvm-svn: 211466

We can just split targets_to_build in one place and make it immutable.

llvm-svn: 210496

All the tests are under the clang tests and none should be under llvm moving
forward.

The topic was discussed in this thread:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140428/214905.html

llvm-svn: 208234

clang should not be used in the llvm tests.  The topic was discussed in this
thread:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140428/214905.html

llvm-svn: 207976

This makes it *really* easy to debug leaks FYI:

ASAN_OPTIONS=detect_leaks=1 ./bin/llvm-lit -v <path to test>

llvm-svn: 207874

llvm-svn: 207704

Update lit.cfg with the fact that LLVM can now generate WoA PE/COFF objects.

llvm-svn: 207347

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.

llvm-svn: 205545

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?

llvm-svn: 205050

llvm-svn: 204486

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>

llvm-svn: 201535

This incorporates a couple of fixes reviewed at http://llvm-reviews.chandlerc.com/D2651

llvm-svn: 200440

llvm-svn: 199835

Add --assertion-mode to llvm-config. It emits ON or OFF according to NDEBUG.

llvm-svn: 196329

llvm-mcmarkup, obj2yaml and yaml2obj were missing from the substitutions list,
causing the test suite to fail in a sandboxed environment.

llvm-svn: 193559

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.
llvm-svn: 193459

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
llvm-svn: 193233

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.

llvm-svn: 191835

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.

llvm-svn: 191828