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

Teach Sema::CheckConditionalOperands() to check for ObjCQualifiedIdType's. This fixes a bogus error.

<rdar://problem/5967036> clang on xcode: error: incompatible operand types ('id<DTOutputStreams>' and 'DTFilterOutputStream *')

llvm-svn: 51828

llvm-svn: 51827

llvm-svn: 51826

TranslationUnit object instead of an ASTContext. By default it calls
Initialize(ASTConstext& Context) (to match with the current interface used by
most ASTConsumers).

Modified the ObjC-Rewriter to use InitializeTU, and to tell the TranslationUnit
to not free its Decls.  This is a workaround for: <rdar://problem/5966749>

llvm-svn: 51825

into the 2.3 release branch.

llvm-svn: 51824

now round-trip through assembly and bitcode.

llvm-svn: 51823

llvm-svn: 51822

llvm-svn: 51821

llvm-svn: 51820

llvm-svn: 51819

llvm-svn: 51818

llvm-svn: 51817

llvm-svn: 51816

Some fancy footwork to accommodate embedded preprocessor directives within an interface.

llvm-svn: 51815

llvm-svn: 51814

we did not truncate the value down to i1 with (x&1).  This caused a problem
when the computation of x was nontrivial, for example, "add i1 1, 1" would 
return 2 instead of 0.

This makes the testcase compile into:

...
  llvm_cbe_t = (((llvm_cbe_r == 0u) + (llvm_cbe_r == 0u))&1);
  llvm_cbe_u = (((unsigned int )(bool )llvm_cbe_t));
...

instead of:

...
  llvm_cbe_t = ((llvm_cbe_r == 0u) + (llvm_cbe_r == 0u));
  llvm_cbe_u = (((unsigned int )(bool )llvm_cbe_t));
...

This fixes a miscompilation of mediabench/adpcm/rawdaudio/rawdaudio and
403.gcc with the CBE, regressions from LLVM 2.2. Tanya, please pull 
this into the release branch.

llvm-svn: 51813

This fix involved tightening up needToScanForQualifiers(), which predated ObjCQualifiedIdType.
It also includes a minor tweak to the code that searches for the beginning of the qualified type. If the AST contained the correct beginning of the declaration (i.e. the beginning of the declaration specifiers), this code would be more robust. Since it doesn't, we apply an adhoc heuristic. Note that DeclSpec contains this info...we just don't propagate it to the AST (at present).

llvm-svn: 51812

Hack RewriteObjC::RewriteObjCStringLiteral() to include the filename in the generated code (replacing any non-alphanumeric characters with "_"). This allows header files to contain ObjCStringLiterals.

llvm-svn: 51811