Fix unused-function warning differently from r220853

Rather than executing this code only needed for an assertion even in a
non-asserts build, just roll the function into the assert. The assertion
text literally describes the two cases so it doesn't seem like this
benefits much from having a separate function (& have to hassle about
ifndef NDEBUG it out, etc)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220970 91177308-0d34-0410-b5e6-96231b3b80d8
Fix ARM HVA classification of classes with non-virtual bases

Reuse the PPC64 HVA detection algorithm for ARM and AArch64. This is a
nice code deduplication, since they are roughly identical. A few virtual
method extension points are needed to understand how big an HVA can be
and what element types it can have for a given architecture.

Also make the record expansion code work in the presence of non-virtual
bases.

Reviewed By: uweigand, asl

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220972 91177308-0d34-0410-b5e6-96231b3b80d8
Fix the build

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220974 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer] Rename NewDeleteLeaks checker in the test script.

Fixup to r220289.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220976 91177308-0d34-0410-b5e6-96231b3b80d8
clang-format: [js] Updates to Google's JavaScript style.

The style guide is changing..

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220977 91177308-0d34-0410-b5e6-96231b3b80d8
clang-format: [Java] Improve line breaks around annotations.

Before:
  @SomeAnnotation("With some really looooooooooooooong text") private static final
      long something = 0L;

  void SomeFunction(@Nullable
                    String something) {}

After:
  @SomeAnnotation("With some really looooooooooooooong text")
  private static final long something = 0L;

  void SomeFunction(@Nullable String something) {}

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220984 91177308-0d34-0410-b5e6-96231b3b80d8
ignore -mconstructor-aliases when adding field paddings for asan

Summary:
When we are adding field paddings for asan even an empty dtor has to remain in the code,
so we ignore -mconstructor-aliases if the paddings are going to be added.

Test Plan: added a test

Reviewers: rsmith, rnk, rafael

Reviewed By: rafael

Subscribers: cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220986 91177308-0d34-0410-b5e6-96231b3b80d8
[PowerPC] Initial VSX intrinsic support, with min/max for vector double

Now that we have initial support for VSX, we can begin adding
intrinsics for programmer access to VSX instructions.  This patch
performs the necessary enablement in the front end, and tests it by
implementing intrinsics for minimum and maximum using the vector
double data type.

The main change in the front end is to no longer disallow "vector" and
"double" in the same declaration (lib/Sema/DeclSpec.cpp), but "vector"
and "long double" must still be disallowed.  The new intrinsics are
accessed via vec_max and vec_min with changes in
lib/Headers/altivec.h.  Note that for v4f32, we already access
corresponding VMX builtins, but with VSX enabled we should use the
forms that allow all 64 vector registers.

The new built-ins are defined in include/clang/Basic/BuiltinsPPC.def.

I've added a new test in test/CodeGen/builtins-ppc-vsx.c that is
similar to, but much smaller than, builtins-ppc-altivec.c.  This
allows us to test VSX IR generation without duplicating CHECK lines
for the existing bazillion Altivec tests.

Since vector double is now legal when VSX is available, I've modified
the error message, and changed where we test for it and for vector
long double, since the target machine isn't visible in the old place.
This serendipitously removed a not-pertinent warning about 'long'
being deprecated when used with 'vector', when "vector long double" is
encountered and we just want to issue an error.  The existing tests
test/Parser/altivec.c and test/Parser/cxx-altivec.cpp have been
updated accordingly, and I've added test/Parser/vsx.c to verify that
"vector double" is now legitimate with VSX enabled.

There is a companion patch for LLVM.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220989 91177308-0d34-0410-b5e6-96231b3b80d8
C++-11 [qoi]. Do not warn on missing 'verride' on use of
macros in user code when macros themselves are defined
in a system header. rdar://18295240


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220992 91177308-0d34-0410-b5e6-96231b3b80d8
MS ABI: Properly call global delete when invoking virtual destructors

Summary:
The Itanium ABI approach of using offset-to-top isn't possible with the
MS ABI, it doesn't have that kind of information lying around.

Instead, we do the following:
- Call the virtual deleting destructor with the "don't delete the object
  flag" set.  The virtual deleting destructor will return a pointer to
  'this' adjusted to the most derived class.
- Call the global delete using the adjusted 'this' pointer.

Reviewers: rnk

Subscribers: cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220993 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer] Helpful hints for Windows users of scan-build.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220999 91177308-0d34-0410-b5e6-96231b3b80d8
Have -Wuninitialized catch uninitalized use in overloaded operator arguments.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221000 91177308-0d34-0410-b5e6-96231b3b80d8
Objective-C SDK modernization tool. Use its own option
,-objcmt-migrate-property-dot-syntax, when migarting to use
property-dot syntax in place of messaging expression.
rdar://18839124


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221001 91177308-0d34-0410-b5e6-96231b3b80d8
Implement IRGen for the x86 vectorcall convention

The most complex aspect of the convention is the handling of homogeneous
vector and floating point aggregates.  Reuse the homogeneous aggregate
classification code that we use on PPC64 and ARM for this.

This convention also has a C mangling, and we apparently implement that
in both Clang and LLVM.

Reviewed By: majnemer

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221006 91177308-0d34-0410-b5e6-96231b3b80d8
Fix an accidental self-assignment using std::move in r220723.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221008 91177308-0d34-0410-b5e6-96231b3b80d8
Silence a warning from MSVC "14" by making an enum unsigned

It says there is a narrowing conversion when we assign it to an unsigned
3 bit bitfield.

Also, use unsigned instead of size_t for the Size field of the struct in
question. Otherwise they won't run together in MSVC or clang-cl.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221019 91177308-0d34-0410-b5e6-96231b3b80d8