GCC compatibility: Ignore -finput_charset=UTF-8 argument. It is the default in Clang.
Currently, we fail with an error.

Reviewers: rafael

Reviewed By: rafael

Subscribers: rnk, cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212110 91177308-0d34-0410-b5e6-96231b3b80d8
clang-cl: Ignore /Zc:inline and /Zc:rvalueCast

These flags enable behavior in MSVC that Clang has by default.

/Zc:inline essentially marks all COMDATs as discardable.  In LLVM
parlance, this means using linkonce_odr linkage, which is what we
already do.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212117 91177308-0d34-0410-b5e6-96231b3b80d8
MS ABI: Reference MSVC RTTI from the VFTable

The pointer for a class's RTTI data comes right before the VFTable but
has no name.  To be properly compatible with this, we do the following:
* Create a single GlobalVariable which holds the contents of the VFTable
  _and_ the pointer to the RTTI data.
* Create a GlobalAlias, with appropriate linkage/visibility, that points
  just after the RTTI data pointer.  This ensures that the VFTable
  symbol will always refer to VFTable data.
* Create a Comdat with a "Largest" SelectionKind and stick the private
  GlobalVariable in it.  By transitivity, the GlobalAlias will be a
  member of the Comdat group.  Using "Largest" ensures that foreign
  definitions without an RTTI data pointer will _not_ be chosen in the
  final linked image.

Whether or not we emit RTTI data depends on several things:
* The -fno-rtti flag implies that we should never not emit a pointer to
  RTTI data before the VFTable.
* __declspec(dllimport) brings in the VFTable from a remote DLL. Use an
  available_externally GlobalVariable to provide a local definition of
  the VFTable.  This means that we won't have any available_externally
  definitions of things like complete object locators.  This is
  acceptable because they are never directly referenced.

To my knowledge, this completes the implementation of MSVC RTTI code
generation.

Further semantic work should be done to properly support /GR-.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212125 91177308-0d34-0410-b5e6-96231b3b80d8
AST: Small simplification in VTableBuilder

Stash whether or not we have an RTTI component away instead of
recomputing it.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212127 91177308-0d34-0410-b5e6-96231b3b80d8
Win64: Disable uwtable until we fix .pdata emission in LLVM

LLVM r211399 started emitting .pdata for win64 by default.
Unfortunately, it produces invalid object files.  I plan to fix that
Soon.  For now, don't request unwind tables.  This fixes the clang-cl
self-host on win64.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212137 91177308-0d34-0410-b5e6-96231b3b80d8
Driver: Handle /GR- in a compatible way with MSVC

There are slight differences between /GR- and -fno-rtti which made
mapping one to the other inappropriate.

-fno-rtti disables dynamic_cast, typeid, and does not emit RTTI related
information for the v-table.

/GR- does not generate complete object locators and thus will not
reference them in vftables.  However, constructs like dynamic_cast and
typeid are permitted.

This should bring our implementation of RTTI up to semantic parity with
MSVC modulo bugs.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212138 91177308-0d34-0410-b5e6-96231b3b80d8
CodeGenCXX: Add tests for RTTI in VFTables

This test was supposed to go in with r212125.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212139 91177308-0d34-0410-b5e6-96231b3b80d8
CodeGen: Add some comments describing VFTable CG

No functionality change, just some comments to describe what is going
on.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212142 91177308-0d34-0410-b5e6-96231b3b80d8
clang/test/CodeGenCXX/microsoft-no-rtti-data.cpp: Relax an expression for -Asserts.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212144 91177308-0d34-0410-b5e6-96231b3b80d8
Introduce a FunctionDecl::getReturnTypeSourceRange() utility

This source range is useful for all kinds of diagnostic QOI and refactoring
work, so let's make it more discoverable.

This commit also makes use of the new function to enhance various diagnostics
relating to return types and resolves an old FIXME.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212154 91177308-0d34-0410-b5e6-96231b3b80d8
[OPENMP] Fixed error message reporting for nesting of regions


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212156 91177308-0d34-0410-b5e6-96231b3b80d8
Prevent Clang from crashing on template code.

Fixes PR20110, where Clang hits an assertion failure when it expects that the
sub-expression of a bit cast to pointer to also be a pointer, but gets a value
instead.

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212160 91177308-0d34-0410-b5e6-96231b3b80d8
[OPENMP, C++11] Improve code of InitVLACaptures function.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212162 91177308-0d34-0410-b5e6-96231b3b80d8
Added test for capturing VLA types if the captured variable is a function parameter.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212170 91177308-0d34-0410-b5e6-96231b3b80d8
Don't accept qualified 'int' main return types in C++ or standard C mode

C++ [basic.start.main]p1: "It shall have a return type of type int"

ISO C is also clear about this, so only accept 'int' with qualifiers in GNUMode
C.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212171 91177308-0d34-0410-b5e6-96231b3b80d8
X86: inline all atomic operations up to 128-bits.

The backend *can* cope with all of these now, so Clang should give it the
chance. On CPUs without cmpxchg16b (e.g. the original athlon64) LLVM can reform
the libcalls.

rdar://problem/13496295

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