The coverage bot has been stable for a while:

  http://lab.llvm.org:8080/coverage/coverage-reports/index.html

llvm-svn: 313769

llvm-svn: 313768

I overzealously landed this before I was sure that another change
wouldn't break the build that this change depends on.

This change adds support for sections involved in dynamic loading such
as SHT_DYNAMIC, SHT_DYNSYM, and allocated string tables.

The two added binaries used for tests can be downloaded here and here

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

llvm-svn: 313767

Summary:
The fix for dead stripping analysis in the case of SamplePGO indirect
calls to local functions (r313151) introduced the possibility of an
infinite loop.

Make sure we check for the value being already live after we update it
for SamplePGO indirect call handling.

Reviewers: danielcdh

Subscribers: mehdi_amini, inglorion, llvm-commits, eraman

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

llvm-svn: 313766

Bug pointed out by EricWF.  This would construct a path where
items would be added in the wrong order, potentially leading
to using the wrong tools for testing.

llvm-svn: 313765

We try to evaluate expressions early when possible, but it is not
possible to evaluate them early if they are based on a section.

Before we would get this wrong on ABSOLUTE expressions.

llvm-svn: 313764

Despite a strong CMake warning that this is an unsupported
libcxx build configuration, some bots still rely on being
able to check out lit and libcxx independently with no
LLVM sources, and then run lit against libcxx.

A previous patch broke that workflow, so this is making it work
again.  Unfortunately, it breaks generation of the llvm-lit
script for libcxx, but we will just have to live with that until
a solution is found that allows libcxx to make more use of
llvm build pieces.  libcxx can still run tests by using the
ninja check target, or by running lit.py directly against the
build tree or source tree.

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

llvm-svn: 313763

Remove unneeded attributes from test/DebugInfo/Generic/imported-name-inlined.ll because it was causing failures on pure MIPS builds.

Patch by Miloš Stojanović!

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

llvm-svn: 313762

llvm-svn: 313761

When clang is called as 'target-clang', put deduced target option at
the start of argument list so that option '--target=' specified in command
line could override it.

This change fixes PR34671.

llvm-svn: 313760

Reviewers: bkramer, krasimir

Reviewed By: krasimir

Subscribers: klimek, cfe-commits

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

llvm-svn: 313759

The revision breaks buildbots:
http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/6694/steps/test/logs/stdio

llvm-svn: 313758

llvm-svn: 313757

As Aaron Ballman has pointed out, that is not really correct.
So the key problem there is the invalidity of the testcase.

Revert r313747, and rework testcase in such a way, so these
details (platform-specific default enum sigdness) are
accounted for.

Also, add a C++-specific testcase.

llvm-svn: 313756

llvm-svn: 313755

Summary:
Calls to onDiagnosticsReady were done concurrently before. This sometimes
led to older versions of diagnostics being reported to the user after
the newer versions.

Reviewers: klimek, bkramer, krasimir

Reviewed By: klimek

Subscribers: cfe-commits

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

llvm-svn: 313754

llvm-svn: 313753

llvm-svn: 313752

This version of the patch fixes an off-by-one error causing PR34596. We
do not need to use std::next(BlockIter) when calling updateDepths, as
BlockIter already points to the next element.

Original commit message:
> For large basic blocks with lots of combinable instructions, the
> MachineTraceMetrics computations in MachineCombiner can dominate the compile
> time, as computing the trace information is quadratic in the number of
> instructions in a BB and it's relevant successors/predecessors.

> In most cases, knowing the instruction depth should be enough to make
> combination decisions. As we already iterate over all instructions in a basic
> block, the instruction depth can be computed incrementally. This reduces the
> cost of machine-combine drastically in cases where lots of instructions
> are combined. The major drawback is that AFAIK, computing the critical path
> length cannot be done incrementally. Therefore we only compute
> instruction depths incrementally, for basic blocks with more
> instructions than inc_threshold. The -machine-combiner-inc-threshold
> option can be used to set the threshold and allows for easier
> experimenting and checking if using incremental updates for all basic
> blocks has any impact on the performance.
>
> Reviewers: sanjoy, Gerolf, MatzeB, efriedma, fhahn
>
> Reviewed By: fhahn
>
> Subscribers: kiranchandramohan, javed.absar, efriedma, llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D36619

llvm-svn: 313751

Fix walking over the schedule tree to collect its properties
(Number of permutable bands etc.).

Also add regression tests for these statistics.

llvm-svn: 313750

llvm-svn: 313749

It broke BB:
http://lab.llvm.org:8011/builders/llvm-hexagon-elf/builds/9781

llvm-svn: 313748

Hopefully fixes test-clang-msc-x64-on-i686-linux-RA build.

The underlying problem is that the enum is signed there.
Yet still, it is invalid for it to contain negative values,
so the comparison is always tautological in this case.

No differential, but related to https://reviews.llvm.org/D37629

llvm-svn: 313747

Previously jaml2obj would segfault on empty document.
(without yaml description).
Patch fixes the issue.

Differential revision: https://reviews.llvm.org/D38036

llvm-svn: 313746

Recommit. Original commit was reverted because buildbots broke.
The error was only reproducible in the build with assertions.
The problem was that the diagnostic expected true/false as
bool, while it was provided as string "true"/"false".

Summary:
As requested by Sam McCall:
> Enums (not new I guess). Typical case: if (enum < 0 || enum > MAX)
> The warning strongly suggests that the enum < 0 check has no effect
> (for enums with nonnegative ranges).
> Clang doesn't seem to optimize such checks out though, and they seem
> likely to catch bugs in some cases. Yes, only if there's UB elsewhere,
> but I assume not optimizing out these checks indicates a deliberate
> decision to stay somewhat compatible with a technically-incorrect
> mental model.
> If this is the case, should we move these to a
> -Wtautological-compare-enum subcategory?

Reviewers: rjmccall, rsmith, aaron.ballman, sammccall, bkramer, djasper

Reviewed By: aaron.ballman

Subscribers: jroelofs, cfe-commits

Tags: #clang

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

llvm-svn: 313745

llvm-svn: 313744

llvm-svn: 313743

Correctly determine when [ is part of a structured binding instead of a
lambda.

To be able to reuse the implementation already available, this patch also:
- sets the Previous link of FormatTokens in the UnwrappedLineParser
- moves the isCppStructuredBinding function into FormatToken

Before:
  auto const const &&[x, y] { A *i };

After:
  auto const const && [x, y]{A * i};

Fixing formatting of the type of the structured binding is still missing.

llvm-svn: 313742

Its a PR34648 which was a segfault that happened because
we stored pointers to elements in DenseMap. 
When DenseMap grows such pointers are invalidated.
Solution implemented is to keep elements by pointer
and not by value.

Differential revision: https://reviews.llvm.org/D38034

llvm-svn: 313741

These tests should have been included in r310697 / D34099 but apparently
I missed them.

llvm-svn: 313737

Summary:
This patch tries to vectorize loads of consecutive memory accesses, accessed
in non-consecutive or jumbled way. An earlier attempt was made with patch D26905
which was reverted back due to some basic issue with representing the 'use mask' of
jumbled accesses.

This patch fixes the mask representation by recording the 'use mask' in the usertree entry.

Change-Id: I9fe7f5045f065d84c126fa307ef6ebe0787296df

Reviewers: mkuper, loladiro, Ayal, zvi, danielcdh

Reviewed By: Ayal

Subscribers: mzolotukhin

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

Commit after rebase for patch D36130

Change-Id: I8add1c265455669ef288d880f870a9522c8c08ab
llvm-svn: 313736

llvm-svn: 313735

It broke selfhosting.
http://lab.llvm.org:8011/builders/clang-with-lto-ubuntu/builds/4896

llvm-svn: 313731

Summary: This fixes a bunch of logging-related FIXMEs.

Reviewers: bkramer, krasimir, malaperle

Reviewed By: malaperle

Subscribers: malaperle, klimek, cfe-commits, mgorny

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

llvm-svn: 313730

If a function or variable has a type with no linkage (and is not extern "C"),
any use of it requires a definition within the same translation unit; the idea
is that it is not possible to define the entity elsewhere, so any such use is
necessarily an error.

There is an exception, though: some types formally have no linkage but
nonetheless can be referenced from other translation units (for example, this
happens to anonymous structures defined within inline functions). For entities
with those types, we suppress the diagnostic except under -pedantic.

llvm-svn: 313729

llvm-svn: 313728

llvm-svn: 313727

Older Android API levels don't have ppoll, but LLDB works just fine,
since on Android it always uses pselect anyway.

llvm-svn: 313726

This reverts commit r313722.

It looks like compiler-rt/lib/tsan/rtl/tsan_libdispatch_mac.cc cannot be
compiled because some of the functions declared in the file do not match
the ones in the SDK headers (which are annotated with 'noescape').

llvm-svn: 313725

[X86] Remove isel checks for immediate size on floating point compare and xop compare instructions. NFCI

If these checks fail we end up not selecting an instruction at all. So we are already relying on the immediate being checked upstream of isel. So doing the check in isel is just bloat to the isel table. Interestingly, we didn't check on the AVX512 version of the instructions anyway.

llvm-svn: 313724