These add no value but can make a class non-trivially copyable. NFC.

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

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

Patch by Bernard Solomon, tests by me.

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

Also fix the test for "core options" to actually fail
in case an option isn't supported.

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

This patch corresponds to review:
http://reviews.llvm.org/D8930

This just adds a front end option to let the back end know the target has PPC
direct move instructions.


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

Summary:
The patch is generated using clang-tidy misc-use-override check.

This command was used:

  tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \
    -checks='-*,misc-use-override' -header-filter='llvm|clang' -j=32 -fix

Reviewers: dblaikie

Reviewed By: dblaikie

Subscribers: klimek, cfe-commits

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

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

Previously, many error messages would simply be "read-only variable is not
assignable"  This change provides more information about why the variable is
not assignable, as well as note to where the const is located.

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



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

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

Follow-up to r234666.  With this, the -m[no-]global-merge options
have the expected behavior. Previously, -mglobal-merge was ignored,
and there was no way of enabling the optimization.


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

Summary:
tools::arm::getARMFloatABI() was falling back to guessing soft-float because
it wasn't seeing the GNUEABIHF environment from ComputeEffectivClangTriple
when it was called from gnutools::Assemble::ConstructJob.

Fix by using the effective clang triple in gnutools::Assemble, which now
matches the -triple flag used by cc1 and ClangAs jobs.

Reviewers: jvoung

Subscribers: rengolin, jfb, aemerson, cfe-commits

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

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

More fallout from r228234; when looking up an identifier in a PCH that
imports the Cocoa module on Darwin, it was taking 2 to 5 seconds
because we were hammering the MapVector::erase() function, which is
O(n).  For now, just clear() the contained SmallVector to get back to
0.25 - 0.5 seconds.  This is probably not the long-term fix, because
without modules or without PCH the performance is more like 0.02
seconds.

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

bridge casting to super class of object's bridge type.
rdar://18311183


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

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

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

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

Take advantage of the delayed typo no longer being eagerly corrected to
a keyword to filter out keyword corrections (and other things like
unresolved & overloaded expressions, which have placeholder types) when
correcting typos inside of a decltype().

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

Sorry, fogot to "git add" the previous time.

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

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

Such helpers should always be comdat with the parent function and have
internal linkage.

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

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

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

Even though these symbols are in a comdat group, the Microsoft linker
really wants them to have internal linkage.

I'm planning to tweak the mangling in a follow-up change. This is a
straight revert with a 1-line fix.

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

The placement of the 'delete' call that was removed in the unique_ptr
migration in r234597 was not an accident. The raw_ostream has to be
destroyed before you do the rename on Windows, otherwise you get
ERROR_ACCESS_DENIED. We can still use unique_ptr, we just need to do a
manual reset().

Also, range-for-loop-ify this code.

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

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

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

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

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

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

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

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

No functional change intended.

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

Emit a code for reduction clause. Next code should be emitted for reductions:

static kmp_critical_name lock = { 0 };

void reduce_func(void *lhs[<n>], void *rhs[<n>]) {
  ...
  *(Type<i> *)lhs[i] = RedOp<i>(*(Type<i> *)lhs[i], *(Type<i> *)rhs[i]);
  ...
}

... void *RedList[<n>] = {&<RHSExprs>[0], ..., &<RHSExprs>[<n> - 1]};
switch (__kmpc_reduce{_nowait}(<loc>, <gtid>, <n>, sizeof(RedList), RedList, reduce_func, &<lock>)) {
case 1:
  ...
  <LHSExprs>[i] = RedOp<i>(*<LHSExprs>[i], *<RHSExprs>[i]);
  ...
  __kmpc_end_reduce{_nowait}(<loc>, <gtid>, &<lock>);
  break;
case 2:
  ...
  Atomic(<LHSExprs>[i] = RedOp<i>(*<LHSExprs>[i], *<RHSExprs>[i]));
  ...
  break;
default:
  ;
}
Reduction variables are a kind of a private variables, they have private copies, but initial values are chosen in accordance with the reduction operation.

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



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

Now that TailRecursionElimination has been fixed with r222354, the
threshold on size for lifetime marker insertion can be removed. This
only affects named temporary though, as the patch for unnamed temporaries
is still in progress.

My previous commit (r222993) was not handling debuginfo correctly, but
this could only be seen with some asan tests. Basically, lifetime markers
are just instrumentation for the compiler's usage and should not affect
debug information; however, the cleanup infrastructure was assuming it
contained only destructors, i.e. actual code to be executed, and was
setting the breakpoint for the end of the function to the closing '}', and
not the return statement, in order to show some destructors have been
called when leaving the function. This is wrong when the cleanups are only
lifetime markers, and this is now fixed.

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

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

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

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

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

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

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

Given something like 'int({}, 1)', we would try to emit a diagnostic
regarding the excess element in the scalar initializer.  However, we
assumed that the initializer list had an element in it.

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