This change is based on the discussion from http://lists.llvm.org/pipermail/llvm-dev/2016-May/098990.html.

The goal is to make the default LLVM configuration build deterministically.

llvm-svn: 268441

Summary:
Adds stat/__xstat to the common interceptors.

Removes the now-duplicate stat/__xstat interceptor from msan/tsan/esan.
This adds stat/__xstat to asan, which previously did not intercept it.

Reviewers: aizatsky, eugenis

Subscribers: tberghammer, danalbert, srhines, kubabrecka, llvm-commits, vitalybuka, eugenis, kcc, bruening

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

llvm-svn: 268440

Reviewed-by: lhames
llvm-svn: 268438

The surrounding tools can cope these days, and they were invented for a reason.

llvm-svn: 268437

llvm-svn: 268436

Both bfd and gold have this. It allows disabling build-id when it is the
default with by adding -Wl,--build-id=none no the clang command line.

llvm-svn: 268435

We have it for StringRef but not ArrayRef, and ArrayRef has drop_back,
so I see no reason it shouldn't have drop_front. Splitting this out of a
change that I have that will use this funcitonality.

llvm-svn: 268434

llvm-svn: 268433

The change reflects llvm r268431.

Patch by Michael Lemay (michael.lemay@intel.com)

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

llvm-svn: 268432

Patch by Michael LeMay (michael.lemay@intel.com)

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

llvm-svn: 268431

Summary:
Speedup the misc-static-assert check by not use `stmt()` as the toplevel matcher.
The framework runs a filter on the matchers before trying them on each node and
uses the toplevel type for this.
Using `stmt()` as the toplevel causes the matcher to be run on every `Stmt` node,
even if the node doesn't match the desired types.

This change speeds up clang-tidy by ~5% in a benchmark.

Reviewers: alexfh

Subscribers: cfe-commits

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

llvm-svn: 268430

In preparation for porting this pass to the new PM.

llvm-svn: 268429

CovMapFuncReader::get should propagate up errors from InstrProfSymtab.

This is part of a series of patches to transition ProfileData over to
the stricter Error/Expected interface.

llvm-svn: 268428

Summary:
One of the big limitations we have in the compiler-rt build system today is that we cannot bootstrap building the builtins because you need a fully functional toolchain to pass CMake's tests.

This change adds support for compile only tests.

It is NFC because nothing is using the compile-only tests yet.

I believe this is the last separable part of D16653.

Reviewers: samsonov

Subscribers: llvm-commits

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

llvm-svn: 268427

Summary:
Replaces {} with a do..while sequence in esan's empty interceptors to allow
natural use with a trailing semicolon.  The sequence uses each argument to
avoid warnings.

Reviewers: filcab

Subscribers: kubabrecka, llvm-commits, zhaoqin

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

llvm-svn: 268426

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

llvm-svn: 268425

pointing to the same addr space. This can prevent SROA from creating a bitcast
between pointers with different addr spaces.

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

llvm-svn: 268424

llvm-svn: 268423

Use a utility function to check whether the number of elements is a power of 2
and drop the redundant upper limit (a 128-bit vector with more than 16 elements
would have each element < 8 bits, not possible).

llvm-svn: 268422

llvm-svn: 268421

Check for success values in the CoverageMappingTest unit test file.

This is part of a series of patches to transition ProfileData over to
the stricter Error/Expected interface.

llvm-svn: 268420

llvm-svn: 268419

If we are devirtualizing, then we want to compute the 'this' adjustment
of the devirtualized target, not the adjustment of the base's method
definition, which is usually zero.

Fixes PR27621

llvm-svn: 268418

llvm-svn: 268417

We were seeing an internal failure when running this test.  I can't
see a good reason for the difference, but the simple fix is to use
%{{.*}} instead of %1.

llvm-svn: 268416

can only be used on named values.

https://llvm.org/bugs/PR23497

llvm-svn: 268415

The replaced load may have implicit-defs and those defs may be used
in the block of the original load. Make sure to update the liveness
accordingly.

This is a generalization of r267817.

llvm-svn: 268412

Introduce a special symbol type to indicate that we have not yet seen a type
for the symbol, so we should not report TLS mismatches for that symbol.

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

llvm-svn: 268411

Found with UBSan.

llvm-svn: 268410

llvm-svn: 268409

SCEV caches whether SCEV expressions are loop invariant, variant or
computable.  LICM breaks this cache, almost by definition; so clear the
SCEV disposition cache if LICM changed anything.

llvm-svn: 268408

Added some tests despite being NFC, since it looks like nothing was
exercising the "all incoming values to exit PHIs are same" logic.

llvm-svn: 268407

`Loop::makeLoopInvariant` can hoist instructions out of loops, so loop
dispositions for the loop it operated on may need to be cleared.  We can
be smarter here (especially around how `forgetLoopDispositions` is
implemented), but let's be correct first.

Fixes PR27570.

llvm-svn: 268406

In the "LoopDispositions:" section:

 - Instead of printing out a list, print out a "dictionary" to make it
   obvious by inspection which disposition is for which loop.  This is
   just a cosmetic change.

 - Print dispositions for parent _and_ sibling loops.  I will use this
   to write a test case.

llvm-svn: 268405

We want --reproduce to

* not rewrite scripts and thin archives
* work with absolute paths

Given that, it pretty much has to create a full directory tree. On windows that
is problematic because of the very short maximum path limit. On most cases
users can still work around it with "--repro c:\r", but that is annoying and
not viable for automated testing.

We then need to produce some form of archive with the files. The first option
that comes to mind is .a files since we already have code for writing them.
There are a few problems with them

The format has a dedicated string table, so we cannot start writing it until
all members are known.
Regular implementations don't support creating directories. We could make
llvm-ar support that, but that is probably not a good idea.
The next natural option would be tar. The problem is that to support long path
names (which is how this started) it needs a "pax extended header" making this
an annoying format to write.

The next option I looked at seems a natural fit: cpio files.

They are available on pretty much every unix, support directories and long path
names and are really easy to write. The only slightly annoying part is a
terminator, but at least gnu cpio only prints a warning if it is missing, which
is handy for crashes. This patch still makes an effort to always create it.

llvm-svn: 268404

command other than the first one is past the end of the load commands.

This is like the test case in test/Object/macho-invalid.test for
macho64-invalid-incomplete-load-command but it is the second load command
that is past the end of all the load commands instead of the first.

The code in the constructor for MachOObjectFile that loops over the load
commands used getNextLoadCommandInfo() which was not producing
a good error message.  So that was fixed and a test case was added.

llvm-svn: 268403

Check for success values in the InstrProfTest unit test file.

This is part of a series of patches to transition ProfileData over to
the stricter Error/Expected interface.

llvm-svn: 268402

Based on post commit feedback from Eric Fiselier.

llvm-svn: 268401

Be more specific in describing compression failures. Also, check for
this kind of error in emitNameData().

This is part of a series of patches to transition ProfileData over to
the stricter Error/Expected interface.

llvm-svn: 268400

llvm-svn: 268398