For now just handles simple comparisons of an ANDed value with zero.
The CC value provides enough information to do any comparison for a
2-bit mask, and some nonzero comparisons with more populated masks,
but that's all future work.

llvm-svn: 189469

The MSA control registers have been added as reserved registers,
and are only used via ISD::Copy(To|From)Reg. The intrinsics are lowered
into these nodes.

llvm-svn: 189468

[mips][msa] Added f[cs]af, f[cs]or, f[cs]ueq, f[cs]ul[et], f[cs]une, fsun, ftrunc_[su], hadd_[su], hsub_[su], sr[al]r, sr[al]ri

llvm-svn: 189467

Two changes:
* Don't add an extra penalty on breaking the same token multiple times.
  Generally, we should prefer not to break, but once we break, the
  normal line breaking penalties apply.
* Slightly increase the penalty for breaking comments. In general, the
  author has put some thought into how to break the comment and we
  should not overwrite this unnecessarily.

With a 40-column column limit, formatting
  aaaaaa("aaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaa");

Leads to:
Before:
  aaaaaa(
      "aaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaa "
      "aaaaaaaaaaaaaaaa");

After:
  aaaaaa("aaaaaaaaaaaaaaaa "
         "aaaaaaaaaaaaaaaa "
         "aaaaaaaaaaaaaaaa");

llvm-svn: 189466

Adds a comment to the start of each test summarizing the area the test covers.

llvm-svn: 189465

llvm-svn: 189464

These operations "vector add high-half narrow" actually correspond to the
sequence:

    %sum = add <4 x i32> %lhs, %rhs
    %high = lshr <4 x i32> %sum, <i32 16, i32 16, i32 16, i32 16>
    %res = trunc <4 x i32> %high to <4 x i16>

Now that LLVM can spot this, Clang should emit the corresponding LLVM IR.

llvm-svn: 189463

The NEON intrinsics vqdmlal and vqdmlsl are really just combinations of a
saturating-doubling-multiply (vqdmull) and a saturating add/sub, so now that
LLVM can spot those patterns Clang should emit them instead of specialised
intrinsics.

Feature already tested by existing ARM NEON intrinsics tests.

llvm-svn: 189462

llvm-svn: 189461

The code leading to a segfault was:
  #pragma omp threadprivate(y)), // long comment leading to a line break

This fixes llvm.org/PR16513.

llvm-svn: 189460

If escaped newlines are aligned right
(FormatStyle.AlignEscapedNewlinesLeft == false), and a line contained
too many characters to fit into the column limit, this would result in
a (virtually) endless loop creating a negative number of spaces.

Instead, allow the escaped newlines to be pushed past the column limit
in this case.

This fixes llvm.org/PR16515.

llvm-svn: 189459

This uses the infrastructure added for memcpy and memmove in r189331.

llvm-svn: 189458

[asan]: fix a CHECK failure in use-after-return mode; enable and fix stack-use-after-return.cc; add a test for UAR mode in asan_noinst_test 

llvm-svn: 189457

llvm-svn: 189456

Before:
  #if __has_include( <strstream>)
  #include <strstream>
  #endif

After:
  #if __has_include(<strstream>)
  #include <strstream>
  #endif

This fixes llvm.org/PR16516.

llvm-svn: 189455

llvm-svn: 189454

In
  @implementation ObjcClass
  - (void)method;
  {
  }
  @end
the ObjC compiler seems to accept the superfluous comma after "method",
but clang-format used to assert on the subsequent "{".

This fixes llvm.org/PR16604.

llvm-svn: 189453

Summary:
-fno-exceptions does not implicitly attach a nothrow specifier to every operator
new. Even in this mode, non-nothrow new must not return a null pointer. Failure
to allocate memory can be signalled by other means, or just by killing the
program. This behaviour is consistent with the compiler - even with
-fno-exceptions, the generated code never tests for null (and would segfault if
the opeator actually happened to return null).

Reviewers: jordan_rose

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D1528

llvm-svn: 189452

Before:
  std::this_thread::sleep_for(std::chrono::nanoseconds{
    std::chrono::seconds { 1 }
  } /
                              5);

After:
  std::this_thread::sleep_for(
      std::chrono::nanoseconds{ std::chrono::seconds{ 1 } } / 5);

This fixes llvm.org/PR16554.

llvm-svn: 189451

Before:
  SomeLoooooooooooooooooooooooooogType operator>
      >(const SomeLooooooooooooooooooooooooogType &other);
  SomeLoooooooooooooooooooooooooogType // break
      operator>>(const SomeLooooooooooooooooooooooooogType &other);

After:
  SomeLoooooooooooooooooooooooooogType
  operator>>(const SomeLooooooooooooooooooooooooogType &other);
  SomeLoooooooooooooooooooooooooogType // break
  operator>>(const SomeLooooooooooooooooooooooooogType &other);

This fixes llvm.org/PR16328.

llvm-svn: 189450

Before:
  static constexpr bool Bar = decltype(bar()) ::value;

After:
  static constexpr bool Bar = decltype(bar())::value;

llvm-svn: 189449

llvm-svn: 189448

This is breaking numerous Clang tests on the buildbot.

llvm-svn: 189447

llvm-svn: 189446

llvm-svn: 189445

llvm-svn: 189444

[CMake] use combination of CMAKE_RUNTIME_OUTPUT_DIRECTORY and CMAKE_LIBRARY_OUTPUT_DIRECTORY to install clang headers for Xcode builds.

llvm-svn: 189443

The previous default was almost, but not quite enough digits to
represent a floating-point value in a manner which preserves the
representation when it's read back in.  The larger default is much
less confusing.

I spent some time looking into printing exactly the right number of
digits if a precision isn't specified, but it's kind of complicated,
and I'm not really sure I understand what APFloat::toString is supposed
to output for FormatPrecision != 0 (or maybe the current API specification
is just silly, not sure which).  I have a WIP patch if anyone is interested.

llvm-svn: 189442

As Chandler pointed out, we should not be using -backend-option because this
will cause crashes for users of the tooling interface, etc. A better way to fix
this will be to provide the unrolling pass-manager flag to the loop vectorizer
directly.

Original commit message:

Disable loop vectorizer unrolling when no unrolling requested

In addition to the regular loop unrolling transformation, the loop vectorizer
can also unroll loops. If no unrolling has specifically been requested (by
-fno-unroll-loops), and the loop vectorizer will be used, then add the backend
option to (also) prevent the loop vectorizer from unrolling loops.

I confirmed with Nadav (off list) that disabling vectorizer loop unrolling when
-fno-unroll-loops is provided is the desired behavior.

llvm-svn: 189441

In addition to the regular loop unrolling transformation, the loop vectorizer
can also unroll loops. If no unrolling has specifically been requested (by
-fno-unroll-loops), and the loop vectorizer will be used, then add the backend
option to (also) prevent the loop vectorizer from unrolling loops.

I confirmed with Nadav (off list) that disabling vectorizer loop unrolling when
-fno-unroll-loops is provided is the desired behavior.

llvm-svn: 189440

in use supports it.

llvm-svn: 189439

The individual group and subgroups tables are now two large tables. The option table stores an index into these two tables instead of pointers. This reduces the size of the options tabe since it doesn't need to store pointers. It also reduces the number of relocations needed.

My build shows this reducing DiagnosticsIDs.o and the clang binary by ~20.5K. It also removes ~400 relocation entries from DiagnosticIDs.o.

llvm-svn: 189438

For now, (defined(X86_64_JIT) && defined(__CYGWIN__)) satisfies Cygwin64.

llvm-svn: 189437

In the LLVM side, x86_64-cygwin is almost as same as x86_64-mingw32.

llvm-svn: 189436

llvm-svn: 189435

This adds the msbuild integration files to the install, provides batch scripts
for (un)installing it in a convenient way, and hooks up the nsis installer to
run those scripts.

Differential Revision: http://llvm-reviews.chandlerc.com/D1537

llvm-svn: 189434

[BumpPtrAllocator] Move DefaultSlabAllocator to a member of BumpPtrAllocator, instead of a static variable.

The problem with having DefaultSlabAllocator being a global static is that it is undefined if BumpPtrAllocator
will be usable during global initialization because it is not guaranteed that DefaultSlabAllocator will be
initialized before BumpPtrAllocator is created and used.

llvm-svn: 189433

Also, fix predicates.

llvm-svn: 189432

No functionality change.

llvm-svn: 189431

llvm-svn: 189430