constant shows up in the assembly language output. Helps with
debugging without a HP calculator having to be handy.

llvm-svn: 51885

issue is operand promotion for setcc/select... but looks like the fundamental
stuff is implemented for CellSPU.

llvm-svn: 51884

llvm-svn: 51883

objc message send in an initializer expression.

llvm-svn: 51882

and insertvalue and extractvalue instructions.

First-class array values are not trivial because C doesn't
support them. The approach I took here is to wrap all arrays
in structs. Feedback is welcome.

The 2007-01-15-NamedArrayType.ll test needed to be modified
because it has a "not grep" for a string that now exists,
because array types now have associated struct types, and
those struct types have names.

llvm-svn: 51881

Fix <rdar://problem/5976164> clang ObjC rewriter: for ... in enumeration inserts undeclared function (objc_enumerationMutation should be in preamble)

llvm-svn: 51880

llvm-svn: 51879

llvm-svn: 51878

in DAGISelEmitter output. This bug was recently uncovered by the
addition of patterns for CALL32m and CALL64m, which are nodes
that now have both MemOperands and variadic_ops.

This bug was especially visible with PIC in various configurations,
because the new patterns are matching the indirect call code used
in many PIC configurations.

llvm-svn: 51877

llvm-svn: 51876

is longer than the second one) should stop after finding one. Added break 
instruction guarantees it. It also changes difference between offsets to 
absolute value of this difference in the condition.

llvm-svn: 51875

llvm-svn: 51872

llvm-svn: 51871

hash_map/hash_set/iterator to have a .h suffix.

llvm-svn: 51867

llvm-svn: 51865

llvm-svn: 51864

out of instcombine into a new file in libanalysis.  This also teaches
ComputeNumSignBits about the number of sign bits in a constantint.

llvm-svn: 51863

this plugs the leak of attributes and also fixes a crash in the test

llvm-svn: 51862

char a[200];
init(a, a+200);

OR

int a[200];
char* b = (char*)a;
char* c = (char*)a;
foo(b, c);

llvm-svn: 51850

llvm-svn: 51849

llvm-svn: 51848

llvm-svn: 51847

llvm-svn: 51846

llvm-svn: 51845

llvm-svn: 51844

llvm-svn: 51843

llvm-svn: 51842

llvm-svn: 51841

Patch by David Chisnall.

llvm-svn: 51840

much closer to passing the gcc struct layout tests.

It might be possible to refactor this a bit, but I'm not sure there's 
actually enough common code for that to be useful.

To get the calling convention completely correct, a bit of 
platform-specific code is necessary even for x86-Linux. On x86-Linux, the
alignment of function parameters is extremely strange; as far as I can tell,
it's always 4 except for SSE vectors or structs containing SSE vectors.  I'm 
continuing to investigate this.

llvm-svn: 51839

llvm-svn: 51838

llvm-svn: 51837

llvm-svn: 51836

Implemented by David Chisnall!

llvm-svn: 51835

the conditions for performing the transform when only the
function declaration is available: no longer allow turning
i32 into i64 for example.  Only allow changing between
pointer types, and between pointer types and integers of
the same size.  For return values ptr -> intptr was already
allowed; I added ptr -> ptr and intptr -> ptr while there.
As shown by a recent objc testcase, changing the way
parameters/return values are passed can be fatal when calling
code written in assembler that directly manipulates call
arguments and return values unless the transform has no
impact on the way they are passed at the codegen level.
While it is possible to imagine an ABI that treats integers
of pointer size differently to pointers, I don't think LLVM
supports any so the transform should now be safe while still
being useful.

llvm-svn: 51834

llvm-svn: 51833

This eliminates a bogus warning identified in the test below.

This fixes <rdar://problem/5968256> clang on xcode: error: incompatible type initializing 'NSObject<XCSelectionSource> *', expected 'id<NSObject,XCSelectionSource>'

llvm-svn: 51832

values, so as to avoid warnings on some platforms.

llvm-svn: 51831

Add some more test cases that demonstrate clang is a bit stricter than GCC. These can be fixed lazily if they become a problem.

llvm-svn: 51830

llvm-svn: 51829