Add a test for MS-ABI this adjustment for virtual calls to member operators.

They too were fixed by r223185, despite the commit message saying otherwise.
Add a test that makes sure they don't regress.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223714 91177308-0d34-0410-b5e6-96231b3b80d8
Revert "Driver: Objective-C should respect -fno-exceptions"

This reverts commit r223455.  It's been succesfully argued that
-fexceptions (at the driver level) is a misnomer and has little to do
with -fobjc-exceptions.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223723 91177308-0d34-0410-b5e6-96231b3b80d8
[modules] If the same .pcm file is imported via two different paths, don't
complain that the contained modules are defined twice.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223724 91177308-0d34-0410-b5e6-96231b3b80d8
DebugInfo: Correctly identify the location of C++ member initializer list elements

This particularly helps the fidelity of ASan reports (which can occur
even in these examples - if, for example, one uses placement new over a
buffer of insufficient size - now ASan will correctly identify which
member's initialization went over the end of the buffer).

This doesn't cover all types of members - more coming.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223726 91177308-0d34-0410-b5e6-96231b3b80d8
MS ABI: Add another test for PR20017

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223733 91177308-0d34-0410-b5e6-96231b3b80d8
[modules] Add experimental -fmodule-map-file-home-is-cwd flag to -cc1.

For files named by -fmodule-map-file=, and files found by 'extern module'
directives, this flag specifies that we should resolve filenames relative to
the current working directory rather than relative to the directory in which
the module map file resides. This is aimed at fixing path handling, in
particular for relative -I paths, when building modules that represent
components of the current project (rather than libraries installed on the
current system, which the current project has as dependencies, where we'd
typically expect the module map files to be looked up implicitly).


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223753 91177308-0d34-0410-b5e6-96231b3b80d8
Revert "[modules] Add experimental -fmodule-map-file-home-is-cwd flag to -cc1."

This reverts commit r223753.  It broke the Green Dragon build for a few
hours:

  http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_build/2259/
  http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_build/2259/consoleFull#43901905849ba4694-19c4-4d7e-bec5-911270d8a58c

I suspect `clang-tools-extra` just needs a follow-up for an API change,
but I'm not the right one to look into it.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223759 91177308-0d34-0410-b5e6-96231b3b80d8
Re-work the Clang system for classifying Intel x86 CPUs to use their
basic microarchitecture names, and add support (with tests) for parsing
all of the masic microarchitecture names for CPUs documented to be
accepted by GCC with -march. I didn't go back through the 32-bit-only
old microarchitectures, but this at least brings the recent architecture
names up to speed. This is essentially the follow-up to the LLVM commit
r223769 which did similar cleanups for the LLVM CPUs.

One particular benefit is that you can now use -march=westmere in Clang
and get the LLVM westmere processor which is a different ISA variant (!)
and so quite significant.

Much like with r223769, I would appreciate the Intel folks carefully
thinking about the macros defined, names used, etc for the atom chips
and newest primary x86 chips. The current patterns seem quite strange to
me, especially here in Clang.

Note that I haven't replicated the per-microarchitecture macro defines
provided by GCC. I'm really opposed to source code using these rather
than using ISA feature macros.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223776 91177308-0d34-0410-b5e6-96231b3b80d8
Don't actually generate code for testing the frontend's target cpu flag,
just verify. This should fix the bots where the x86 backend isn't built
into Clang. Sorry for the breakage.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223779 91177308-0d34-0410-b5e6-96231b3b80d8
IR: Update clang for Metadata/Value split in r223802

Match LLVM API changes from r223802.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223803 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a GCC error from r223803

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223814 91177308-0d34-0410-b5e6-96231b3b80d8
DebugInfo: Emit the correct location for initialization of a complex variable

Especially useful for sanitizer reports.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223825 91177308-0d34-0410-b5e6-96231b3b80d8
DebugInfo: Accurate location information for complex assignment

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223828 91177308-0d34-0410-b5e6-96231b3b80d8
DebugInfo: Correct location for compound complex assignment

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223835 91177308-0d34-0410-b5e6-96231b3b80d8
DebugInfo: Correct the location of initializations of auto.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223839 91177308-0d34-0410-b5e6-96231b3b80d8
DebugInfo: Correct location of initialization of auto __complex

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223842 91177308-0d34-0410-b5e6-96231b3b80d8
Objective-C SDK modernizer. Modernize to use 
property-dot-syntax when receiver is 'super'. 
rdar://19140267


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223846 91177308-0d34-0410-b5e6-96231b3b80d8
clang-format: Add a test for PR19603 which seems fixed (maybe by r221338?).


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223850 91177308-0d34-0410-b5e6-96231b3b80d8
AST: Don't assume two zero sized objects live at different addresses

Zero sized objects may overlap with each other or any other object.

This fixes PR21786.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223852 91177308-0d34-0410-b5e6-96231b3b80d8
DebugInfo: Correct location of aggregate assignment

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