template template parameters and dependent template names. For
example, the oft-mentioned

  typename MetaFun::template apply<T1, T2>::type

can now be instantiated, with the appropriate name lookup for "apply".

llvm-svn: 68128

Does not work well on 32 bit targets. Bug reported by Albert Graef.

This patch also adds new "-Wllc,option" syntax to pass options to llc.

llvm-svn: 68127

llvm-svn: 68126

Patch by David Chisnal.

llvm-svn: 68125

possible to run the tests with -asm-verbose defaulting
to false.

llvm-svn: 68124

llvm-svn: 68122

 - Patch by Ed Schouten!

llvm-svn: 68121

Patch by Jay Foad.

llvm-svn: 68120

 - Always pass -triple to clang-cc (-arch will be removed).

 - clang-cc doesn't play guess work with the target triple anymore.

llvm-svn: 68119

llvm::sys::getOS{Name,Version}.

Right now the implementation just derives from LLVM_HOSTTRIPLE (which
is wrong, but it doesn't look like we have a define for the target
triple). Ideally this routine would actually be able to compute the
triple for targets we care about.

llvm-svn: 68118

llvm-svn: 68117

llvm-svn: 68116

llvm-svn: 68115

Changed GenerateConstantString() to take an ObjCStringLiteral (instead of a std::string). While this isn't strictly necessary, it seems cleaner and allows us to cache to "containsNonAscii" if necessary (to avoid checking in both Sema and CodeGen).

llvm-svn: 68114

llvm-svn: 68113

llvm-svn: 68112

llvm-svn: 68111

llvm-svn: 68110

llvm-svn: 68109

This fixes <rdar://problem/6712496> Unable to disable deprecated warning.

llvm-svn: 68108

llvm-svn: 68107

In a case like:

@class foo;
foo *P;

addRecordToClass was making an empty shadow struct for the foo interface and
completing it.  Later when an:

@interface foo
...
@endif

foo *Q;

was seen, ASTContext::addRecordToClass would think that foo was already laid
out and not lay out the definition.  This fixes it to create a forward declared
struct the first time around, then complete it when the definition is seen.

Note that this causes two tests to regress, because something is trying to get
the size of the forward declared structs returned by this.  Previously, this
would end up getting a size of zero but now it properly dies.  I'm not sure
what the right solution is for this, so I xfailed the tests.

Fariborz, please take a look at this.  The testcase in rdar://6676794 now gets
farther, but dies later because the objc ivar is not assigned a field number.

As an aside, I really don't like the fact that the objc front-end is creating
shadow C structs for ObjC types.  This seems like an implementation detail of
the code generator that could be fixed by better factoring of the extant code.

llvm-svn: 68106

llvm-svn: 68105

is run for perfectly reasonable things like NSString* because type
layout is recursive.

llvm-svn: 68104

llvm-svn: 68103

llvm-svn: 68102

Fix BuildAggrIvarLayout to not access vectors out of range.

llvm-svn: 68101

llvm-svn: 68100

llvm-svn: 68099

llvm-svn: 68098

llvm-svn: 68095

llvm-svn: 68094

Remove the "fast" cases for spill and restore point determination, as these were subtlely wrong in obscure cases.  Patch the testcase
to account for this change.

llvm-svn: 68093

llvm-svn: 68092

llvm-svn: 68091

disable this feature for now, to err on the side of rejecting instead
of sometimes crashing.  rdar://6326239

llvm-svn: 68088

llvm-svn: 68087

llvm-svn: 68086

llvm-svn: 68085

llvm-svn: 68084