llvm-svn: 51949

hardcoded data layout in getTargetDescription.  Hopefully fixes a test 
failure.

Of course, this should be fixed properly, but that's a bigger fix.

llvm-svn: 51948

llvm-svn: 51947

Add CallSite::hasArgument to allow for seeing if a call passes a certain value as an argument quickly.

llvm-svn: 51946

Add a Name parameter to two of the init methods of GetElementPointer to make the name setting more consistent.

llvm-svn: 51945

(http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080602/063306.html).

llvm-svn: 51944

Moved LangOptions from TranslationUnit to ASTContext.  This induced a variety of cleanups in some ASTConsumers.

llvm-svn: 51943

llvm-svn: 51942

llvm-svn: 51941

llvm-svn: 51939

Sema::ActOnClassMessage() needs to look through it's local implementation for private class methods.

llvm-svn: 51938

Add a Name argment to two init methods in these classes as well to make things
a bit more consistent.

llvm-svn: 51937

llvm-svn: 51936

llvm-svn: 51934

llvm-svn: 51933

llvm-svn: 51932

llvm-svn: 51931

llvm-svn: 51930

are the same as in unpacked structs, only field
positions differ.  This only matters for structs
containing x86 long double or an apint; it may
cause backwards compatibility problems if someone
has bitcode containing a packed struct with a
field of one of those types.
The issue is that only 10 bytes are needed to
hold an x86 long double: the store size is 10
bytes, but the ABI size is 12 or 16 bytes (linux/
darwin) which comes from rounding the store size
up by the alignment.  Because it seemed silly not
to pack an x86 long double into 10 bytes in a
packed struct, this is what was done.  I now
think this was a mistake.  Reserving the ABI size
for an x86 long double field even in a packed
struct makes things more uniform: the ABI size is
now always used when reserving space for a type.
This means that developers are less likely to
make mistakes.  It also makes life easier for the
CBE which otherwise could not represent all LLVM
packed structs (PR2402).
Front-end people might need to adjust the way
they create LLVM structs - see following change
to llvm-gcc.

llvm-svn: 51928

for reporting this.

llvm-svn: 51926

Fixes <rdar://problem/5984338> clang on xcode: property implementation must have its declaration in interface 'PBXOpenQuicklyModule'

llvm-svn: 51925

llvm-svn: 51924

Added support for mips little endian arch => mipsel

llvm-svn: 51923

llvm-svn: 51922

llvm-svn: 51921

llvm-svn: 51920

Fix <rdar://problem/5967199> clang on xcode: error: member reference is not to a structure or union

llvm-svn: 51919

moves the check for the invalid construct to a point where it doesn't 
affect other uses of isIntegerConstantExpr, and we can warn properly 
when the extension is used.  This makes it a bit more complicated, but 
it's a lot cleaner.

Steve, please tell me if this check is sufficient to handle the 
relevant system header.  I know it's enough to handle the testcase, but 
I don't know what exactly the original looks like.

llvm-svn: 51918

llvm-svn: 51917

llvm-svn: 51916

Don't crash when we encounter one of these.

llvm-svn: 51915

llvm-svn: 51913

llvm-svn: 51911

llvm-svn: 51910

assembler names of string constants look like.

llvm-svn: 51909

Add a builtin. Fixes <rdar://problem/5982037> clang on xcode: error: incompatible operand types ('int' and 'char *').

llvm-svn: 51908

Change Expr::isIntegerConstantExpr() to allow for pointer types (for GCC compatibility). Note FIXME.

Fix <rdar://problem/5977870> clang on xcode: error: arrays with static storage duration must have constant integer length

llvm-svn: 51907

llvm-svn: 51904

Allow implicit pointer/int conversions on ObjCQualifiedIdTypes in Sema::CheckCompareOperands() and Sema::CheckAssignmentConstraints().

Fixes <rdar://problem/5980804> clang on xcode: error: incompatible type sending 'id<XDUMLType>', expected 'NSCellType'.

llvm-svn: 51902

llvm-svn: 51901