Summary:
This allows them to be used without -cc1 the same way as -I and -isystem.
Renamed the options to --system-header-prefix=/--no-system-header-prefix to avoid interference with -isystem and make the intent of the option cleaner.

Reviewers: rsmith

Reviewed By: rsmith

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D3185

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

Conceptually one of these loops is just a while-loop, but the actual code-gen
is more complicated. We don't instrument all the different control flow edges
to get accurate counts for each conditional branch, nor do I think it makes
sense to do so. Instead, make the simplifying assumption that the loop behaves
like a while-loop. Use the same branch weights for the first check for an
empty collection as would be used for the back-edge of a while loop, and use
that same weighting for the innermost loop, ignoring the possibility that there
may be some extra code to go fetch more elements.

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

in a lambda capture.


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

Review feedback from Reid Kleckner on r203603.

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

If there are any scope specifiers, then a base class must be named or
the symbol isn't from a base class.

Fixes PR19233.

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

Fixes PR19240.  In retrospect, this is a fairly obvious bug.  :)

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

Fix an logic error in the clang driver preventing crtfastmath.o from linking when -Ofast is used without -ffast-math

In gcc using -Ofast forces linking of crtfastmath.o.
In the current clang crtfastmath.o is only linked when -ffast-math/-funsafe-math-optimizations passed. It can lead to performance issues, when using only -Ofast without explicit -ffast-math (I faced with it).
My patch fixes inconsistency with gcc behaviour and also introduces few tests on it.

Patch by Zinovy Nis!

Differential Revision: http://llvm-reviews.chandlerc.com/D3114

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

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

A refinement of r198953 to handle cases where an object is accessed both through
a property getter and through direct ivar access. An object accessed through a
property should always be treated as +0, i.e. not owned by the caller. However,
an object accessed through an ivar may be at +0 or at +1, depending on whether
the ivar is a strong reference. Outside of ARC, we don't have that information,
so we just don't track objects accessed through ivars.

With this change, accessing an ivar directly will deliberately override the +0
provided by a getter, but only if the +0 hasn't participated in other retain
counting yet. That isn't perfect, but it's already unusual for people to be
mixing property access with direct ivar access. (The primary use case for this
is in setters, init methods, and -dealloc.)

Thanks to Ted for spotting a few mistakes in private review.

<rdar://problem/16333368>

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

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

Two DynTypedNodes can be equal if they do not have the same node type,
because DynTypedNodes for the same underlying object might have been
created from different types (for example, Decl vs VarDecl).

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

Before:
  STATIC_ASSERT((a &b) == 0);

After:
  STATIC_ASSERT((a & b) == 0);

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

deserialization.


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

an out-of-date external decls list). This happens if we declare some names,
force the lookup table for the decl context to be built, import a module that
adds more decls for the name, then write out our module without looking up the
name.


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

If a DeclContext's lookups need to be reconciled, and we're given external declarations for a name, reconcile first. Otherwise, when we come to reconcile, we'll ask for external declarations for that name again. No functionality change intended.


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

lookups for a DeclContext.


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

specialization would make us think it might have a key function.


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

Similar to the implementation for globals in r157167.

Patch by Jingyue Wu.


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

COFF doesn't have mergeable sections so LLVM/clang's normal tactics for
string deduplication will not have any effect.

To remedy this we place each string inside it's own section and mark
the section as IMAGE_COMDAT_SELECT_ANY.  However, we can only do this if the
string has an external name that we can generate from it's contents.

To be compatible with MSVC, we must use their scheme.  Otherwise identical
strings in translation units from clang may not be deduplicated with
translation units in MSVC.

This fixes PR18248.

N.B. We will not attempt to do anything with a string literal which is not of
type 'char' or 'wchar_t' because their compiler does not support unicode
string literals as of this date.  Further, we avoid doing this if
either -fwritable-strings or -fsanitize=address are present.

This reverts commit r204596.

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

As of cl.exe version 18, the special layout rules for structs with 
alignment 16 or greater has been dropped.  This patch drops the behavior 
from clang.  This patch also updates the lit tests to reflect the 
change.



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

plain old CHECKs.

Follow-up to r204633.

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

Update the powerpc64le check to include CALL_ELF=2 check.
This is a testcase follow-up to r204627.
(see also r204614 for CALL_ELF usage).





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

Capability attributes can now be declared on a typedef declaration as well as a structure declaration. This allows for C code to use Boolean expressions on a capability as part of another attribute. Eg) __attribute__((requires_capability(!SomeCapability)))

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

This was failing on an internal branch where the order was different for
some reason. <rdar://problem/16407581>

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

Additional clarification from Uli for the background on _CALL_ELF:
"Historically GCC has provided various _CALL_... predefines depending on the
ABI currently being compiled for. (_CALL_SYSV,_CALL_AIXDESC, _CALL_DARWIN )
When we needed a new define for the current ABI, we decided on using _CALL_ELF
since the official name of the ABI is the OpenPower ElfV2 ABI, with the
current Linux ABI retro-actively being renamed the ELFv1 ABI
and so we decided on using _CALL_ELF to identify the Linux (+BSD etc.) ELF ABI,
with _CALL_ELF=1 for the v1 ABI and _CALL_ELF=2 for the v2 ABI.
(Note that this matches the gcc compiler switch -mabi=elfv1 vs. -mabi=elfv2)."

In code, a (_CALL_ELF==2) check will indicate when the ELFv2 ABI is
to be used.   This is the desired default for the PPC64 LE target.



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

Update the parameters passed to the assembler and linker for
the PPC64LE target.  Specifically:
(assembler) adds/uses  -mppc64 -mlittle-endian
(linker) adds/uses  elf64lppc

Testcase included.



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

Update DataLayout/DescriptionString for ppc64le

Similar LLVM change made in r203664

Testcase included.




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

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

lib/CodeGen/CGBuiltin.cpp:3136:12: warning: variable ‘TblPos’ set but not used [-Wunused-but-set-variable]

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

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

Thanks to Richard Smith for catching this!

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

Use two check-prefix patterns per FileCheck invocation for these tests,
this cleanly removes redundant CHECK directives.

Thanks to Richard Smith for the idea!

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

This commit cleans up a few accidents:
- Do not rely on the order in which StringLiteral lays out bytes.
- Use a more efficient mechanism for handling so-called
  "special-mappings" when mangling string literals.
- There is no need to allocate a copy of the mangled name.
- Add the test written for r204562.

Thanks to Richard Smith for pointing these out!

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

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

Proper redeclaration warnings for dllimport are not implemented yet.

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

dllimport implies a definition which means the 'extern' keyword is optional
when declaring imported variables.

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

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

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

namespace, we need to update both the visible names of that namespace and of
its enclosing namespace set.


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

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