llvm-svn: 209441

It just seems wrong. This fixes llvm.org/PR19736.

llvm-svn: 209440

llvm-svn: 209439

Before:
  template <int> struct A4 { A4() { }
  };

After:
  template <int i> struct A4 {
    A4() {}
  };

This fixes llvm.org/PR19813 (at least the part that isn't working as
intended).

llvm-svn: 209438

This brings "-arch armv7m" (etc) behaviour more in line with what's expected
for developers on OS X, and allows Clang to find an "ld" (for example) in the
same directory instead of using the default /usr/bin/ld.

Unfortunately no test because it relies on the specific place Clang is running
from.

rdar://problem/16427320

llvm-svn: 209437

Patch by Florian Zeitz

llvm-svn: 209436

This reverts r209433. Sorry about that, it needs a test & better message.

llvm-svn: 209435

When "-arch armv7m" is specified, we want "aapcs", for example.

rdar://problem/16581138

llvm-svn: 209434

llvm-svn: 209433

Use stack protector strong by default to match the base OS and ports/packages
compiler policy.

Patch by Brad Smith.

llvm-svn: 209432

Before:
  static_assert(std::is_integral<int> {} + 0, "");
  int a = std::is_integral<int> {}
  + 0;

After:
  static_assert(std::is_integral<int>{} + 0, "");
  int a = std::is_integral<int>{} + 0;

llvm-svn: 209431

llvm-svn: 209430

llvm-svn: 209429

Before:
  int foo(int i) {
    return fo1 {}
    (i);
  }
  int foo(int i) {
    return fo1 {}
    (i);
  }

After:
  int foo(int i) { return fo1{}(i); }
  int foo(int i) { return fo1{}(i); }

This fixes llvm.org/PR19812.

llvm-svn: 209428

[ASan/Win] Use the new function interception approach to handle function wrappers too; wrap strlen() in DLLs

Reviewed at http://reviews.llvm.org/D3871

llvm-svn: 209427

We should be keeping track of the writeback on these instructions,
otherwise we're relying on LLVM's stupidity for correct code.

Fortunately, the MC layer can now handle all required constraints,
which means we can get rid of the CodeGen only PseudoInsts too.

llvm-svn: 209426

This changes ARM64 to use separate operands for each component of an
address, and look for separate '[', '$Rn, ..., ']' tokens when
parsing.

This allows us to do away with quite a bit of special C++ code to
handle monolithic "addressing modes" in the MC components. The more
incremental matching of the assembler operands also allows for better
diagnostics when LLVM is presented with invalid input.

Most of the complexity here is with the register-offset instructions,
which were extremely dodgy beforehand: even when the instruction used
wM, LLVM's model had xM as an operand. We papered over this
discrepancy before, but that approach doesn't work now so I split them
into separate X and W variants.

llvm-svn: 209425

Summary:
* Split into two functions, one to test each struct.
* R0 and R2 must be defined by an lw with a %got reference to the correct
  symbol.
* Test for $4 (first argument) where appropriate instead of accepting any
  register.
* Test that the two lbu's are correctly combined into $4

Depends on D3844

Reviewers: jkolek, zoran.jovanovic, vmedic

Reviewed By: vmedic

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

llvm-svn: 209424

Summary:
lwl and lwr are not available in MIPS32r6/MIPS64r6. The purpose of the test
is to check that the '$1' expands to '0($x)' rather than to test something related
to the lwl or lwr instructions so we can simply switch to lw.

Depends on D3842

Reviewers: jkolek, zoran.jovanovic, vmedic

Reviewed By: vmedic

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

llvm-svn: 209423

As the memory ownership is handled by the SpecificBumpPtrAllocator
anyway, there is no need to duplicate states when inserting them into
the Seen-set. This leads to an improvement of ~10% on the benchmark
formatting file.

No functional changes intended.

llvm-svn: 209422

Summary:
This patch is necessary so that they do not fail on MIPS32r6/MIPS64r6 when
-integrated-as is enabled by default and we correctly detect the host CPU.

No functional change since these tests are testing the behaviour of the
constraint used for the third operand rather than the mnemonic.

Depends on D3842

Reviewers: zoran.jovanovic, jkolek, vmedic

Reviewed By: vmedic

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

llvm-svn: 209421

llvm-svn: 209420

Summary: Depends on D3787. Tablegen will raise an assertion without it.

Reviewers: zoran.jovanovic, jkolek, vmedic

Reviewed By: vmedic

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

llvm-svn: 209419

Summary:
These emit the 'unknown instruction' instead of the correct error
because they have not been implemented in LLVM for any MIPS ISA.

Reviewers: jkolek, zoran.jovanovic, vmedic

Reviewed By: vmedic

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

llvm-svn: 209418

Discovered by Ahmed Charles in http://reviews.llvm.org/D3018.

llvm-svn: 209417

Reviewed at http://reviews.llvm.org/D3870

llvm-svn: 209416

Summary:
This required me to implement the disassembler for MIPS64r6 since the encodings
are ambiguous with other instructions. This in turn revealed a few
assembly/disassembly bugs which I have fixed.

* da[ht]i only take two operands according to the spec, not three.
* DecodeBranchTarget2[16] correctly handles wider immediates than simm16
  * Also made non-functional change to DecodeBranchTarget and
    DecodeBranchTargetMM to keep implementation style consistent between
    them.
* Difficult encodings are handled by a custom decode method on the most
  general encoding in the group. This method will convert the MCInst to a
  different opcode if necessary.

DecodeBranchTarget is not currently the inverse of getBranchTargetOpValue
so disassembling some branch instructions emit incorrect output. This seems
to affect branches with delay slots on all MIPS ISA's. I've left this bug
for now and temporarily removed the check for the immediate on
bc[12]eqz/bc[12]nez in the MIPS32r6/MIPS64r6 tests.

jialc and jic crash the disassembler for some reason. I've left these
instructions commented out for the moment.

Depends on D3760

Reviewers: jkolek, zoran.jovanovic, vmedic

Reviewed By: vmedic

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

llvm-svn: 209415

llvm-svn: 209414

Before:
  var literal = 'hello ' + 'world';

After:
  var literal = 'hello ' +
                'world';

There is no reason to concatenated two string literals with a '+' unless
the line break is intended.

llvm-svn: 209413

Before:
  int i{a *b};

After:
  int i{a * b};

Also fix unrelated issue where braced init lists were counted as blocks
and prevented single-line functions.

llvm-svn: 209412

This patch adds a helper class (CGLoopInfo) for marking memory instructions with llvm.mem.parallel_loop_access metadata.
It also adds a simple initial version of codegen for pragma omp simd (it will change in the future to support all the clauses).

Differential revision: http://reviews.llvm.org/D3644

llvm-svn: 209411

If simple (one-statement) blocks can be inlined, the length needs to be
calculated correctly.

Before (in JavaScript but this also affects lambdas, etc.):
  var x = {
    valueOf: function() { return 1; }
  };

After:
  var x = {valueOf: function() { return 1; }};

llvm-svn: 209410

Should be no change in behaviour, but it makes the intended
functionality a bit clearer and means we only have to reason about
real extend operations.

llvm-svn: 209409

llvm-svn: 209408

ASTReaderListener's documentation states that visitInputFile will be
called based on the return values of needsInputFileVisitation and
needsSystemInputFileVisitation, but ChainedASTReaderListener may call
these methods on a child listener based on the values returned by the
other child.

Even worse, the calls to visitInputFile may be short-circuited due to
the use of the boolean or, so the calls to visit may not occur at all
for the second listener.

This updates ChainedASTReaderListener::visitInputFile to propagate the
ASTReaderListener behaviour to both children.

llvm-svn: 209394

Properly initialise HadError to false during construction.  Detected as
use-of-uninitialised variable by MSan!

llvm-svn: 209393

llvm-svn: 209392

llvm-svn: 209391

This intrinsic permits the emission of platform specific undefined sequences.
ARM has reserved the 0xde opcode which takes a single integer parameter (ignored
by the CPU).  This permits the operating system to implement custom behaviour on
this trap.  The llvm.arm.undefined intrinsic is meant to provide a means for
generating the target specific behaviour from the frontend.  This is
particularly useful for Windows on ARM which has made use of a series of these
special opcodes.

llvm-svn: 209390

llvm-svn: 209389