This is a CMake var which never evaluates to false.

llvm-svn: 289673

llvm-svn: 289663

Summary:
The current test only checks whether ld64 is available, causing tests
to fail when ld64 is avilable but libLTO is not built.

Reviewers: beanz, mehdi_amini

Subscribers: mehdi_amini, llvm-commits

Differential Revision: https://reviews.llvm.org/D27739

llvm-svn: 289662

llvm-svn: 289504

This reverts commit r249937.

llvm-svn: 289502

This program is for testing features that rely on multi-module bitcode files.
It takes a multi-module bitcode file, extracts one of the modules and writes
it to the output file.

Differential Revision: https://reviews.llvm.org/D26778

llvm-svn: 288201

llvm-strings was added to the test dependencies without updating the lit
substitutions.  Synchronise the list.

llvm-svn: 286773

Usage:

  llvm-xray extract <object file> [-o <filename or '-'>]

The tool gets the XRay instrumentation map from an object file and turns
it into YAML.  We first support ELF64 sleds on x86_64 binaries, with
provision for supporting other supported platforms and formats later.

This is the first of a many-part change to fully implement the
`llvm-xray` tool.

We also define a subcommand registration and dispatch mechanism to be
used by other further subcommand implementations for llvm-xray.

Diffusion Revision: https://reviews.llvm.org/D21987

llvm-svn: 285165

Add a OCAML_INSTALL_PATH variable that can be used to control
the install path for OCaml libraries. The new variable defaults to
${OCAML_STDLIB_PATH}, i.e. the OCaml library path obtained from
the OCaml compiler. Install libraries into "llvm" subdirectory.

This fixes two issues:

1. OCaml library directories differ between systems, and 'lib/ocaml' is
incorrect e.g. on amd64 Gentoo where OCaml is installed
in 'lib64/ocaml'. Therefore, obtain the library path from the OCaml
compiler using 'ocamlc -where' (which is already used to set
OCAML_STDLIB_PATH), which is the method used commonly in OCaml packages.

2. The top-level directory is reserved for the standard library, and has
precedence over local directory in search path. As a result, OCaml
preferred the files installed along with previous LLVM version over the
source tree when building a new version, resulting in two versions being
mixed during the build. The new layout is used commonly by other OCaml
packages, and findlib is able to find the LLVM libraries successfully.

Bug: https://bugs.gentoo.org/559134
Bug: https://bugs.gentoo.org/559624

Differential Revision: https://reviews.llvm.org/D24354

llvm-svn: 282895

This adds a copy of the demangler in libcxxabi.

The code also has no dependencies on anything else in LLVM. To enforce
that I added it as another library. That way a BUILD_SHARED_LIBS will
fail if anyone adds an use of StringRef for example.

The no llvm dependency combined with the fact that this has to build
on linux, OS X and Windows required a few changes to the code. In
particular:

    No constexpr.
    No alignas

On OS X at least this library has only one global symbol:
__ZN4llvm16itanium_demangleEPKcPcPmPi

My current plan is:

    Commit something like this
    Change lld to use it
    Change lldb to use it as the fallback

    Add a few #ifdefs so that exactly the same file can be used in
    libcxxabi to export abi::__cxa_demangle.

Once the fast demangler in lldb can handle any names this
implementation can be replaced with it and we will have the one true
demangler.

llvm-svn: 280732

This restores commit r278330, with fixes for a few bot failures:
- Fix a late change I had made to the save temps output file that I
  missed due to existing files sitting on my disk
- Fix a bunch of Windows bot failures with "ambiguous call to overloaded
  function" due to confusion between llvm::make_unique vs
  std::make_unique (preface the new make_unique calls with "llvm::")
- Attempt to fix a modules bot failure by adding a missing include
  to LTO/Config.h.

Original change:

Resolution-based LTO API.

Summary:
This introduces a resolution-based LTO API. The main advantage of this API over
existing APIs is that it allows the linker to supply a resolution for each
symbol in each object, rather than the combined object as a whole. This will
become increasingly important for use cases such as ThinLTO which require us
to process symbol resolutions in a more complicated way than just adjusting
linkage.

Patch by Peter Collingbourne.

Reviewers: rafael, tejohnson, mehdi_amini

Subscribers: lhames, tejohnson, mehdi_amini, llvm-commits

Differential Revision: https://reviews.llvm.org/D20268

llvm-svn: 278338

This reverts commit r278330.

I made a change to the save temps output that is causing issues with the
bots. Didn't realize this because I had older output files sitting on
disk in my test output directory.

llvm-svn: 278331

Summary:
This introduces a resolution-based LTO API. The main advantage of this API over
existing APIs is that it allows the linker to supply a resolution for each
symbol in each object, rather than the combined object as a whole. This will
become increasingly important for use cases such as ThinLTO which require us
to process symbol resolutions in a more complicated way than just adjusting
linkage.

Patch by Peter Collingbourne.

Reviewers: rafael, tejohnson, mehdi_amini

Subscribers: lhames, tejohnson, mehdi_amini, llvm-commits

Differential Revision: https://reviews.llvm.org/D20268

Address review comments

llvm-svn: 278330

Add the $arch-registered-target features that clang uses to disable
tests that require a registered backend, so that we can run the sancov
tests on Windows. LLVM's lit suite did not appear to have a per-test way
to do this, and I would rather not split up the sancov tests into
architecture directories.

Split out of https://reviews.llvm.org/D23321

llvm-svn: 278271

COFF doesn't support weak linkage on functions.

llvm-svn: 278162

Followup from r277778, after Mehdi's comments.

Expand %ld64 to perform the necessary preload instead, that way new
tests do not need to worry about setting up DYLD_INSERT_LIBRARIES
themselves.

rdar://problem/24300926

llvm-svn: 277788

Green Dragon's darwin stage2 asan bot fails on some checks:
http://lab.llvm.org:8080/green/job/clang-stage2-cmake-RgSan_check

  test/tools/lto/hide-linkonce-odr.ll
  test/tools/lto/opt-level.ll

ERROR: Interceptors are not working. This may be because
AddressSanitizer is loaded too late (e.g. via dlopen)

To fix this, %ld64 needs to load 'libclang_rt.asan_osx_dynamic.dylib'
before libLTO.dylib, via DYLD_INSERT_LIBRARIES. This won't work by
updating config.environment, since some shim binary in the way scrubs
the env vars. Instead, provide the path to this lib through %asanrtlib,
which can then be used by tests directly with DYLD_INSERT_LIBRARIES.

rdar://problem/24300926

llvm-svn: 277778

For example, stop expanding 'opt' in -passes='require<opt-remark-emit>'.

llvm-svn: 276707

Reviewers: mehdi_amini

Subscribers: llvm-commits

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

llvm-svn: 275214

Reviewers: alexfh, wolfgangp, rengolin

Subscribers: llvm-commits

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

llvm-svn: 274949

The logic that sets up lit features for sanitizers is largely copied
between here and clang, except clang's was fixed some time ago to
handle multiple sanitizers (ie, Asan + Ubsan). This just makes the
code in LLVM consistent with how it's done in clang to avoid any
gotchas by users of this.

llvm-svn: 270510

to llvm-objdump. This section is created with -fembed-bitcode option.

This requires the use of libxar and the Cmake and lit support were crafted by
Chris Bieneman!

rdar://26202242

llvm-svn: 270491

This adds llvm-pdbdump to the list of tools which get printed with
the full path in verbose mode.  This makes it easier to take the
whole run line from verbose output and run it again without prepending
with the builds bin directory.

llvm-svn: 268250

We missed a handful of .mir tests that existed outside the
test/CodeGen/MIR directory.

Also fix the three powerpc .mir tests that nobody noticed were broken.

llvm-svn: 265350

llvm-svn: 264764

llvm-svn: 264758

llvm-svn: 262878

This is part of a new statistics gathering feature for the sanitizers.
See clang/docs/SanitizerStats.rst for further info and docs.

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

llvm-svn: 257970

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

llvm-svn: 257236

LLVM_ENABLE_TIMESTAMPS controls if timestamps are embedded into llvm's
binaries. Turning it off is useful for deterministic builds.

r246905 made it so that the define suddenly also controls if the binaries that
the llvm binaries _create_ embed timestamps or not – but this shouldn't be a
configure-time option. r256203/r256204 added a driver option to toggle this on
and off, so this patch now passes this driver option in LLVM_ENABLE_TIMESTAMPS
builds so that if LLVM_ENABLE_TIMESTAMPS is set, the build of LLVM is
deterministic – but the built clang can still write timestamps into other
executables when requested.

This also allows removing some of the test machinery added in r292012 to work
around this problem.

See PR24740 for background.
http://reviews.llvm.org/D15783

llvm-svn: 256958

llvm-svn: 256457

Note, ENABLE_TIMESTAMPS is either 1 or 0 in Makefile.config.

llvm-svn: 256138

Support for COFF timestamps was unintentionally broken in r246905 when
it was conditionally available depending on whether or not LLVM was
configured with LLVM_ENABLE_TIMESTAMPS.  However, Config/config.h was
never included which essentially broke the feature.  Due to lax testing,
the breakage was never identified until we observed strange failures
during incremental links of Chromium.

This issue is resolved by simply including Config/config.h in
WinCOFFObjectWriter and teaching lit that the MC/COFF/timestamp.s test
is conditionally supported depending on LLVM_ENABLE_TIMESTAMPS.  With
this in place, we can strengthen the test to ensure that it will not
accidentally get broken in the future.

This fixes PR25891.

llvm-svn: 256137

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

It has been fixed since r219280 by David Majnemer.

llvm-svn: 256112

llvm-svn: 254360

tool_path will be None for llvm-go if Go cannot be found

llvm-svn: 254190

llvm-svn: 254189

Summary:
When running tests, pass the GO_EXECUTABLE CMake
cache variable to llvm-go. The "go" binary may
not be in $PATH, or may be different to the one
passed to CMake.

Reviewers: pcc

Subscribers: llvm-commits

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

llvm-svn: 254187

llvm-svn: 253525

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

llvm-svn: 253354