This will be used soon from clang.

llvm-svn: 249309

[ARM] armv6m + netbsd. Tests are misssing for armv6m + darwin as well.

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

llvm-svn: 249308

Like i386, Mips needs a versioned interceptor but must select GLIBC_2.2.

llvm-svn: 249307

Summary:

Reviewers: vkalintiris, atanasyan

Subscribers: cfe-commits

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

llvm-svn: 249306

Summary: Add the second template argument to the unique_ptr mock, and update the matcher so that it only matches against cases where the second argument is the default.

Reviewers: klimek

Subscribers: alexfh, cfe-commits

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

llvm-svn: 249305

Tag_Advanced_SIMD_arch is set correctly when targeting v8.1-a NEON.

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

llvm-svn: 249304

This extends the work done in r233995 so that now getFragment (in addition to
getSection) also works for variable symbols.

With that the existing logic to decide if a-b can be computed works even if
a or b are variables. Given that, the expression evaluation can avoid expanding
variables as aggressively and that in turn lets the relocation code see the
original variable.

In order for this to work with the asm streamer, there is now a dummy fragment
per section. It is used to assign a section to a symbol when no other fragment
exists.

This patch is a joint work by Maxim Ostapenko andy myself.

llvm-svn: 249303

llvm-svn: 249302

OpenCL v1.1 s6.2.2: for the boolean value true, every bit in the result vector should be set.

This change treats the i1 value as signed for the purposes of performing the cast to integer,
and therefore sign extend into the result.

Patch by Neil Hickey!

http://reviews.llvm.org/D13349

llvm-svn: 249301

Summary: Now that we prioritize copying trivial types over using const-references where possible, I found some cases where, after the transformation, the loop was using the address of the local copy instead of the original object.

Reviewers: klimek

Subscribers: alexfh, cfe-commits

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

llvm-svn: 249300

Reviewers: jaydeep.
Subscribers: lldb-commits.
Differential Revision: http://reviews.llvm.org/D13335

llvm-svn: 249299

There are two remaining buildbot failures that we'll have to
investigate before submitting this again.

llvm-svn: 249298

The entries are added if there are "_init" or "_fini" entries in
the symbol table respectively. According to the behavior of ld,
entries are inserted even for undefined symbols.

Symbol names can be overridden by using -init and -fini command
line switches. If used, these switches neither add new symbol table
entries nor require those symbols to be resolved.

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

llvm-svn: 249297

Try to make the Windows buildbots happy by fixing the regexes that match the
paths to CRT files.

llvm-svn: 249296

Add symbol specified with -u as undefined which may cause additional
object files from archives to be linked into the resulting binary.

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

llvm-svn: 249295

r249137 added support for the new mips-mti-linux toolchain. However,
the new tests of that commit, broke some buildbots because they didn't use
the correct regular expressions to capture the filename of Clang & LLD.

This commit re-applies the changes of r249137 and fixes the tests in
r249137 in order to match the filenames of the Clang and LLD executable.

llvm-svn: 249294

Summary:
https://llvm.org/bugs/show_bug.cgi?id=24960

modernize-use-nullptr would hit an assertion in some cases involving macros and initializer lists, due to finding a node with more than one parent (the two forms of the initializer list).

However, this doesn't mean that the replacement is incorrect, so instead of just rejecting this case I tried to find a way to make it work. Looking at the semantic form of the InitListExpr made sense to me (looking at both forms results in false negatives) but I am not sure of the things that we can miss by skipping the syntactic form.

Reviewers: klimek

Subscribers: cfe-commits, alexfh

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

llvm-svn: 249291

statement. Specifically, we don't want people that have already written
a patch to just write a style guide for their 1-person project.

llvm-svn: 249290

llvm-svn: 249289

llvm-svn: 249288

llvm-svn: 249287

llvm-svn: 249286

llvm-svn: 249285

llvm-svn: 249284

The target "check-clang-tools" is affected by CLANG_INCLUDE_TESTS but it was undefined in 1st configuration procedure.

llvm-svn: 249283

when building a module.

llvm-svn: 249282

Summary: When LLVM/Clang is built without ARM support, the ios_kext runtime
library is not built, but without this patch, the Makefile still tries to
copy it. This is a recent regression, because the ios_kext library used
to also be built on x86_64.

Reviewers: beanz

Subscribers: aemerson, cfe-commits, rengolin

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

llvm-svn: 249281

We already check for LandingPadInst two lines above.

llvm-svn: 249280

In versions of clang prior to r238238, __declspec was recognized as a keyword in
all modes.  It was then changed to only be enabled when Microsoft or Borland
extensions were enabled (and for CUDA, as a temporary measure).  There is a
desire to support __declspec in Playstation code, and possibly other
environments.  This commit adds a command-line switch to allow explicit
enabling/disabling of the recognition of __declspec as a keyword.  Recognition
is enabled by default in Microsoft, Borland, CUDA, and PS4 environments, and
disabled in all other environments.

Patch by Warren Ristow!

llvm-svn: 249279

llvm-svn: 249278

llvm-svn: 249277

  A statement with an empty domain complicates the invariant load
  hoisting and does not help any subsequent analysis or transformation.
  In fact it might introduce parameter dimensions or increase the
  schedule dimensionality. To this end, we remove statements with an
  empty domain early in the SCoP simplification.

llvm-svn: 249276

llvm-svn: 249275

  The "unprofitable" heuristic was broken and counted boxed loops
  even though we do not represent and optimize them.

llvm-svn: 249274

  Before isValidCFG() could hide the fact that a loop is non-affine by
  over-approximation. This is problematic if a subregion of the loop contains
  an exit/latch block and is over-approximated. Now we do not over-approximate
  in the isValidCFG function if we check loop control.  If such control is
  non-affine the whole loop is over-approximated, not only a subregion.

llvm-svn: 249273

  This patch cannot be tested on its own as the isValidCFG currently
  hides the fact that control is actually non-affine with
  over-approximation. This will be corrected in the next patch and a
  test for non-affine latches will be added.

llvm-svn: 249272

llvm-svn: 249271

Summary:
The bitcode format is described in this document:
  https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view
For more info on ThinLTO see:
  https://sites.google.com/site/llvmthinlto

The first customer is ThinLTO, however the data structures are designed
and named more generally based on prior feedback. There are a few
comments regarding how certain interfaces are used by ThinLTO, and the
options added here to gold currently have ThinLTO-specific names as the
behavior they provoke is currently ThinLTO-specific.

This patch includes support for generating per-module function indexes,
the combined index file via the gold plugin, and several tests
(more are included with the associated clang patch D11908).

Reviewers: dexonsmith, davidxl, joker.eph

Subscribers: llvm-commits

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

llvm-svn: 249270

When the ScopAnnotator was a class member variable some of the maps it contains
have not been properly cleared. As a result we had dangling pointers to
llvm::Value(s) which got detected by the AssertingVH we recently added.

No test case as this issue is hard to reproduce reliably as subsequent
optimizations need to delete some of the llvm::Values we still keep in our
lists.

llvm-svn: 249269

llvm-svn: 249268