llvm-svn: 129823

// rdar://9132143

llvm-svn: 129822

llvm-svn: 129820

redundancy pointed out by John.

llvm-svn: 129808

gcc's unused warnings which don't get emitted if the function is referenced even in an unevaluated context
(e.g. in templates, sizeof, etc.). Also, saying that a function is 'unused' because it won't get codegen'ed
is somewhat misleading.

- Don't emit 'unused' warnings for functions that are referenced in any part of the user's code.
- A warning that an internal function/variable won't get emitted is useful though, so introduce
  -Wunneeded-internal-declaration which will warn if a function/variable with internal linkage is not
  "needed" ('used' from the codegen perspective), e.g:

  static void foo() { }

  template <int>
  void bar() {
    foo();
  }

test.cpp:1:13: warning: function 'foo' is not needed and will not be emitted
static void foo() { }
            ^

Addresses rdar://8733476.

llvm-svn: 129794

CL_AddressableVoid is the expression classification used for void
expressions whose address can be taken, i.e. the result of [], *
or void variable references in C, as opposed to things like the
result of a void function call.

llvm-svn: 129783

llvm-svn: 129750

llvm-svn: 129741

llvm-svn: 129740

llvm-svn: 129734

llvm-svn: 129733

llvm-svn: 129732

Add libclang API to query how much memory is used by a CXTranslationUnit.  This is a WIP.  Currently we report
the amount used for expressions, types, identifiers, and selectors.

llvm-svn: 129730

Add ASTContext::getTotalMemory() to allow clients to query how much memory is bump allocated for declarations, statements, and types.

llvm-svn: 129729

llvm-svn: 129728

llvm-svn: 129721

of conditional expressions of objc pointer types
where one type is the immediate base type of the
other. // rdar://9296866

llvm-svn: 129718

llvm-svn: 129712

llvm-svn: 129704

llvm-svn: 129703

Fix PR9741. The implicit declarations created for range-based for loops weren't being added to the DeclContext (nor were they being marked as implicit). Also, the declarations were being emitted in the wrong order when building the CFG.

llvm-svn: 129700

implementation such as

  @synthesize Prop1 = 

Give priority to ivars whose type matches or closely matches the
property type (as we do for several other kinds of
results). Additionally, if there is an ivar with the same name as the
property, or differs only due to a _ prefix or suffix, give that ivar
a priority bump. Finally, verify that this search is properly
returning ivars within class extensions and implementations
(<rdar://problem/8488854>).

llvm-svn: 129699

llvm-svn: 129698

implementation 

  @synthesize <property> = 

also produce a completion for a to-be-synthesized ivar named
_<property>.

llvm-svn: 129697

llvm-svn: 129682

llvm-svn: 129681

it down.  we effectively were compile the testcase into:

void test14(int x) {
  switch (x) {
    case 11: break;
    case 42: test14(97);  // fallthrough
    default: test14(42); break;

which is not the same thing at all.  This fixes a miscompilation of 
MallocBench/gs seen on the clang-x86_64-linux-fnt buildbot.

llvm-svn: 129679

llvm-svn: 129674

turns out that a field or base needs to be laid out in the tail padding of
the base, CGRecordLayoutBuilder::ResizeLastBaseFieldIfNecessary will convert
it to an array of i8.

I've audited the new test results to make sure that they are still valid. I've
also verified that we pass a self-host with this change.

This (finally) fixes PR5589!

llvm-svn: 129673

llvm-svn: 129672

llvm-svn: 129671

llvm-svn: 129669

Use a SmallVector for field types in CGRecordLayoutBuilder now that llvm::StructType::get takes an ArrayRef.

llvm-svn: 129667

Also, fold the sse4 and sse4.1 cases together.

Patch by Alexander Best!

llvm-svn: 129665

llvm-svn: 129660

properly.

llvm-svn: 129657

a -O0 code quality issue.

llvm-svn: 129652

are trivial.  This exposes opportunities earlier, and allows fastisel
to do good things with these at -O0.

This addresses rdar://9289468 - clang doesn't fold memset_chk at -O0

llvm-svn: 129651

fix rdar://9289603 - clang should fold trivial ?: for enums as well as integer constants into select at -O0
by making the isCheapEnoughToEvaluateUnconditionally predicate handle anything that folds to a constant.  In particular, we now fold enums.

llvm-svn: 129649

llvm-svn: 129629