Wrap to 80 columns. No behavior change.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223149 91177308-0d34-0410-b5e6-96231b3b80d8
Diagnose TypoExprs in a couple of error cases in ParsePostfixExpressionSuffix.

Also have CorrectDelayedTyposInExpr check that the Expr* isn't null
before trying to access its members. Fixes PR21679.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223162 91177308-0d34-0410-b5e6-96231b3b80d8
InstrProf: Remove some pointless indirection (NFC)

It doesn't make much sense to have std::unique_ptrs of std::string and
std::vector. Avoid some useless indirection by using these types
directly.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223166 91177308-0d34-0410-b5e6-96231b3b80d8
Another warning with no group name bites the dust.
rdar://19116886


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223168 91177308-0d34-0410-b5e6-96231b3b80d8
InstrProf: Use the same names for variables as we use in the profile

There's no need to use different names for the local variables than we
use in the profile itself, and it's a bit simpler and easier to debug
if we're consistent.

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

Implement _umul128; it provides the high and low halves of a 128-bit
multiply.  We can simply use our __int128 arithmetic to implement this,
we generate great code for it:
        movq    %rdx, %rax
        mulq    %rcx
        movq    %rdx, (%r8)
        retq

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223175 91177308-0d34-0410-b5e6-96231b3b80d8
Intrin: shrx_u64 should be _shrx_u64

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223176 91177308-0d34-0410-b5e6-96231b3b80d8
Ensure typos in the default values of template parameters get diagnosed.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223177 91177308-0d34-0410-b5e6-96231b3b80d8
FullProduct should be _FullProduct

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223179 91177308-0d34-0410-b5e6-96231b3b80d8
PR21706: -Wunsequenced was missing warnings when leaving a sequenced region that contained side effects.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223184 91177308-0d34-0410-b5e6-96231b3b80d8
Fix incorrect codegen for devirtualized calls to virtual overloaded operators.

Consider this program:

    struct A {
      virtual void operator-() { printf("base\n"); }
    };
    struct B final : public A {
      virtual void operator-() override { printf("derived\n"); }
    };

    int main() {
      B* b = new B;
      -static_cast<A&>(*b);
    }

Before this patch, clang saw the virtual call to A::operator-(), figured out
that it can be devirtualized, and then just called A::operator-() directly,
without going through the vtable.  Instead, it should've looked up which
operator-() the call devirtualizes to and should've called that.

For regular virtual member calls, clang gets all this right already. So
instead of giving EmitCXXOperatorMemberCallee() all the logic that
EmitCXXMemberCallExpr() already has, cut the latter function into two pieces,
call the second piece EmitCXXMemberOrOperatorMemberCallExpr(), and use it also
to generate code for calls to virtual member operators.

This way, virtual overloaded operators automatically don't get devirtualized
if they have covariant returns (like it was done for regular calls in r218602),
etc.

This also happens to fix (or at least improve) codegen for explicit constructor
calls (`A a; a.A::A()`) in MS mode with -fsanitize-address-field-padding=1.

(This adjustment for virtual operator calls seems still wrong with the MS ABI.)


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223185 91177308-0d34-0410-b5e6-96231b3b80d8
Add support for has_feature(cxx_alignof) and has_feature(c_alignof).

r142020 added support for has_feature(cxx_alignas). This does the same for
alignof.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223186 91177308-0d34-0410-b5e6-96231b3b80d8
UBSan now uses prologue data instead of prefix data

As the semantics of prefix data has changed. See D6454.

Patch by Ben Gamari!

Test Plan: Testsuite

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223190 91177308-0d34-0410-b5e6-96231b3b80d8
Update test to check for prologue instead of prefix

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223191 91177308-0d34-0410-b5e6-96231b3b80d8
Handle delayed corrections in a couple more error paths in ParsePostfixExpressionSuffix.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223209 91177308-0d34-0410-b5e6-96231b3b80d8
Preserve LD_LIBRARY_PATH when using the 'env' command

In many Linux environments (and similar), just-built applications won't run
correctly without making use of the current LD_LIBRARY_PATH environmental
variable in order to find dynamic libraries. Propagate it through the 'env'
command (hopefully this works on all platforms).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223219 91177308-0d34-0410-b5e6-96231b3b80d8
[OPENMP] Code formatting and improvement, no functional changes.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223225 91177308-0d34-0410-b5e6-96231b3b80d8
clang-format: Fix expression parser not closing stuff at end of stmt.

Uncovered by a Java test case:

Before:
  public some.package.Type someFunction( // comment
      int parameter) {}

After:
  public some.package.Type someFunction( // comment
                          int parameter) {}

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223228 91177308-0d34-0410-b5e6-96231b3b80d8
clang-format: Fix fake parentheses placement with comments.

Before:
  return (a > b
          // comment1
      // comment2
      || c);

After:
  return (a > b
      // comment1
      // comment2
      || c);

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223234 91177308-0d34-0410-b5e6-96231b3b80d8
Fix isThreadModelSupported()'s comment. NFC

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