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

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

not support as a possible reason for choosing GCC instead of Clang (and vice
versa). Weaken some of the claimed advantages of Clang in light of GCC
improvements.


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

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

Before this patch GetOrCreateLLVMFunction would add a decl to
DeferredDeclsToEmit even when it was being called by the function trying to
emit that decl.

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

While testing our ability to mangle large constants (PR18175), I
incidentally discovered that we did not properly mangle enums correctly.

Previously, we would append the width of the enum in bytes after the
type-tag differentiator.

This would mean "enum : short" would be mangled as 'W2' while "enum :
char" would be mangled as 'W1'.  Upon testing this with several versions
of MSVC, I found that this did not match their behavior: they always use
'W4'.

N.B.  Quick testing uncovered that undname allows different numbers to
follow the 'W' in the following way:

'W0' -> "enum char"
'W1' -> "enum unsigned char"
'W2' -> "enum short"
'W3' -> "enum unsigned short"
'W4' -> "enum"
'W5' -> "enum unsigned int"
'W6' -> "enum long"
'W7' -> "enum unsigned long"

However this scheme appears abandoned, I cannot get MSVC to trigger it.
Furthermore, it's incomplete: it doesn't handle "bool" or "long long".


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

    int32_t vminv_s32(int32x2_t a) 
which should be compiled into SMINP Vd.2S,Vn.2S,Vm.2S


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

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

VerifyDiagnosticConsumer is long-lived so the two additional members shouldn't
have any impact on release builds.

The clang headers are now free of NDEBUG conditionals. Let's keep it that way!

Note that they're not yet structurally stable, pending a few fixes in the LLVM
core headers.

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

This should get it up and running on win and other builders without system
headers.

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

Add -verify and update the test directives to match current expectations.

Also add a FIXME to an ObjC test that has expected-* directives but no -verify.

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

Going by PR6913 it looks like this one can no longer reach CodeGen so remove
the redundant -emit-llvm case and treat it as an ordinary Sema test.

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

LLVM r196044 should make it pass.

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

There's no evidence that a 'DISABLE' directive ever existed.

Let's see if anything breaks..

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

These were being substituted into approximately the following:

  clang -cc1 -internal-isystem ../lib/clang/3.5/include_only

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

Due to a missing -verify, 2007-10-01-BuildArrayRef.c was a no-op.

The message was changed 5 years ago so also update the test to reflect the new wording.

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

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

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

We already support using "r" on 64-bit values (a GPRPair is
allocated), but Sema doesn't know this yet so issues a warning. This
should fix it.

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

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

argh!




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

Add back the test that was triggering the assertion (which I removed mistakenly thinking it was triggering just a warning and not an assertion).  My error was brought to my attention by Rafael (Thanks!).



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

architecture and PIC flag.


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

Clang outputs LLVM one top level decl at a time. This combined with the
visibility computation code looking for the newest NamespaceDecl would cause
it to produce different results for nested namespaces.

The two options for producing consistent results are
* Delay codegen of anything inside a namespace until the end of the file.
* Don't look for the newest NamespaceDecl.

This patch implements the second option.
This matches the gcc behavior too.

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

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

Employed the following refactorings:
  - Renamed some functions
  - Introduced explaining variables
  - Cleaned up & added comments
  - Used Optional<unsigned> for return value instead of an out parameter
  - Added assertions
  - Constified a few member functions
  
No functionality change.
All regressions pass.  



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

This can happen when we're trying to emit a thunk with available_externally
linkage with optimization enabled but bail because it doesn't make sense
for vararg functions.

PR18098.

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

assert(sanity()) reads so much better than preprocessor conditional blocks.

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

Code in headers shouldn't be conditional on the build configuration.

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

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

There was already a condition earlier in the function so just place the check
there.

Cleanup only.

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

__builtin_types_compatible_p() isn't a C++ type trait at all, rather a GNU C
special-case, so it's fine to use BoolTy the default return type for binary
type traits.

This brings BTT in line with other arities that already default to BoolTy.

Cleanup only, no change in behaviour.

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

attribute is acceptable.

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

instantiation appears in a non-enclosing namespace (the previous diagnostic
talked about the C++98 rule even in C++11 mode).


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

and MIPS64. From Brad Smith.


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

attribute in sema and issuing a variety of diagnostics lazily 
for misuse of this attribute (and what to do) when converting 
from CF types to ObjectiveC types (and vice versa).
// rdar://15499111


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

Also includes a minor refactor with no functional change.



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

This tests the bug fix in llvm r196620.

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

Added support for mcpu krait

- krait processor currently modeled with the same features as A9.
- Krait processor additionally has VFP4 (fused multiply add/sub)
and hardware division features enabled.
- krait has currently the same Schedule model as A9
- krait cpu flag is not recognized by the GNU assembler yet,
it is replaced with march=armv7-a to avoid a lower march
from being used.




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

Was accidently passing the file to clang twice. No functionaly change.


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