llvm-svn: 264954

llvm-svn: 264953

llvm-svn: 264952

llvm-svn: 264951

llvm-svn: 264950

llvm-svn: 264949

llvm-svn: 264948

llvm-svn: 264947

llvm-svn: 264946

llvm-svn: 264945

llvm-svn: 264944

llvm-svn: 264943

llvm-svn: 264942

llvm-svn: 264941

Fixes https://llvm.org/bugs/show_bug.cgi?id=27129 which is crash involving type
aliases and template type diffing.  Template arguments for type aliases and
template arguments for the underlying desugared type may not have one-to-one
relations, which could mess us the attempt to get more information from the
desugared type.  For type aliases, ignore the iterator over the desugared type.

llvm-svn: 264940

llvm-svn: 264939

This test should fail on OS X Yosemite and older, and pass on OS X El Capitan
and newer as well as on other platforms.

llvm-svn: 264938

Fixes https://llvm.org/bugs/show_bug.cgi?id=26014

Reviewed by Richard Smith.

llvm-svn: 264937

r264884 introduced a helper to escape the backslashes in the source file
path, but I since discovered an existing mechanism to escape strings.

llvm-svn: 264936

Commit r260791 contained an error in that it would introduce a cross-module
reference in the old module. It also introduced O(N^2) complexity in the
module cloner by requiring the entire module to be visited for each function.
Fix both of these problems by avoiding use of the CloneDebugInfoMetadata
function (which is only designed to do intra-module cloning) and cloning
function-attached metadata in the same way that we clone all other metadata.

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

llvm-svn: 264935

#endif was one line too low.  If KMP_USE_ADAPTIVE_LOCKS is 0,
then queuing locks would incorrectly use drdpa lock mechanism.
This is a fix for https://llvm.org/bugs/show_bug.cgi?id=26649

llvm-svn: 264934

llvm-svn: 264933

Silencing warnings from MSVC 2015 Update 2. Both of these changes silence "C4334 '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)". NFC.

llvm-svn: 264932

This is identical to the other r600 datalayout string.

llvm-svn: 264931

Summary:
When the code is compiled for arm32 and the builtin `__va_list` declaration is created by `CreateAAPCSABIBuiltinVaListDecl`, the declaration is not saved in the `ASTContext` which may lead to a compilation error or crash.

Minimal reproducer I was able to find:
**header.h**
```
#include <stdarg.h>
typedef va_list va_list_1;
```

**test.cpp**
```
typedef __builtin_va_list va_list_2;
void foo(const char* format, ...) { va_list args; va_start( args, format ); }
```

Steps to reproduce:
```
clang -x c++-header --target=armv7l-linux-eabihf header.h
clang -c -include header.h --target=armv7l-linux-eabihf test.cpp
```

Compilation error:
```
error: non-const lvalue reference to type '__builtin_va_list'
      cannot bind to a value of unrelated type 'va_list' (aka '__builtin_va_list')
```

Compiling the same code as a C source leads to a crash:
```
clang --target=armv7l-linux-eabihf header.h
clang -c -x c -include header.h --target=armv7l-linux-eabihf test.cpp
```

Reviewers: logan, rsmith

Subscribers: cfe-commits, asl, aemerson, rengolin

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

llvm-svn: 264930

Silencing warnings from MSVC 2015 Update 2. All of these changes silence "C4334 '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)". NFC.

llvm-svn: 264929

For the same reason as the corresponding load change.

Note that ExpandStore is completely broken for non-byte sized element
vector stores, but preserve the current broken behavior which has tests
for it. The behavior should be the same, but now introduces a new typed
store that is incorrectly split later rather than doing it directly.

llvm-svn: 264928

On AMDGPU we want to be able to promote i64/f64 loads to v2i32.
If the access is unaligned, this would conclude that since i64 is legal,
it would convert it back to i64 and there is an endless legalization
loop.

Extract the logic for scalarizing the load into a new TargetLowering
function, where this can also replace the custom function AMDGPU
has for this.

llvm-svn: 264927

Widening a PHI requires us to insert a trunc.
The logical place for this trunc is in the same BB as the PHI.
This is not possible if the BB is terminated by a catchswitch.

This fixes PR27133.

llvm-svn: 264926

We already get it right, but there was no coverage for it.

llvm-svn: 264925

This updates most of the file handling methods in the linking context and
resolver to use the new API.

llvm-svn: 264924

llvm-svn: 264923

Fix for issue introduced D17297, where we were breaking early from the loop detecting consecutive loads which could leave us thinking a consecutive load with zeros was possible.

llvm-svn: 264922

llvm-svn: 264921

Summary:
IsOverload has a param named UseUsingDeclRules.  But as far as I can
tell, it should be called UseMemberUsingDeclRules.  That is, it only
applies to "using" declarations inside classes or structs.

Reviewers: rsmith

Subscribers: cfe-commits

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

llvm-svn: 264920

Summary:
Currently it's a module pass.  Make it a function pass so that we can
move it to PassManagerBuilder's EP_EarlyAsPossible extension point,
which only accepts function passes.

Reviewers: rnk

Subscribers: tra, llvm-commits, jholewinski

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

llvm-svn: 264919

[PassManager] Make PassManagerBuilder::addExtension take an std::function, rather than a function pointer.

Summary:
This gives callers flexibility to pass lambdas with captures, which lets
callers avoid the C-style void*-ptr closure style.  (Currently, callers
in clang store state in the PassManagerBuilderBase arg.)

No functional change, and the new API is backwards-compatible.

Reviewers: chandlerc

Subscribers: joker.eph, cfe-commits

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

llvm-svn: 264918

Pretty mechanical change here.  Just replacing all the std::error_code() with
llvm::Error() and make_dynamic_error_code with make_error<GenericError>

llvm-svn: 264917

The TailDup transform was removed in r138841 in 2011, along with most
of the tests for it. This test, however, was missed. Probably because
it had already been XFAIL'd for 3 years at that point (since r52243!)
and continued to fail when the opt flag for -tailduplicate stopped
being valid.

llvm-svn: 264916

Windows seems to complain that the file cannot be removed because
it is still in use. We don't have to remove the file but instead
just overwrite it, so do that.

llvm-svn: 264915