llvm-svn: 72747

llvm-svn: 72743

 - Avoids running any LLVM optimizations, even at -O2, etc., while still keeping
   any language changes these optimizations imply.

llvm-svn: 72742

llvm-svn: 72737

Fixes an error recovery issue which caused a crash.

llvm-svn: 72733

llvm-svn: 72728

Also, committing an #if 0'ed __builtin_setjmp and __builtin_longjmp 
implementation I've had sitting in my tree for a while.  I haven't 
enabled it because the LLVM backend support isn't complete yet.

llvm-svn: 72727

llvm-svn: 72726

section of the users manual.

llvm-svn: 72725

# line directives.

llvm-svn: 72724

llvm-svn: 72723

alloca without declaring it.

llvm-svn: 72719

llvm-svn: 72718

llvm-svn: 72717

llvm-svn: 72716

very much, but I have a feeling we're never going to have an 
implementation that makes sense because of compatibility issues.

llvm-svn: 72715

llvm-svn: 72714

llvm-svn: 72713

in merge_types. It is incomplete. We probably want to issue 
a warning if user attempts to change the attribute from __weak to
__strong or vice-vera. It also assumes that a __weak/__strong
attribute can not be specified with other (currently one) type
attriute. 

llvm-svn: 72711

directory exist.

llvm-svn: 72704

for the Next runtime.

llvm-svn: 72703

not runaable.

llvm-svn: 72695

llvm-svn: 72694

llvm-svn: 72691

K&R-style definition.

llvm-svn: 72690

definition variadic.  I'm not completely sure it's legal, but the 
standard can be interpreted as making it legal, and gcc seems to think 
it's legal, so I didn't add an extension warning.

llvm-svn: 72689

llvm-svn: 72687

preprocessor.

llvm-svn: 72686

properties at the moment:

1. It allows stuff like "__strong id x; __weak id x;".

2. For constructs like "__strong id x; id x;", subsequent references to 
x lose the objc_gc attribute.

3. This incorrectly allows merges involving the address_space attribute.

4. Constructs like "id x; /* some code using x */ __weak id x;" don't 
apply the objc_gc attribute consistently to all uses of x.

The first three can probably be fixed relatively easily; the fourth 
would be extremely difficult to fix.

llvm-svn: 72683

llvm-svn: 72682

llvm-svn: 72681

After spending 15 minutes trying to figure out why this was crashing, I realized it was a bug in the test case :)

llvm-svn: 72680

llvm-svn: 72679

llvm-svn: 72678

llvm-svn: 72677

llvm-svn: 72676

llvm-svn: 72675

llvm-svn: 72674

Make sure to copy back arguments that can be changed by FindAllocationOverload. This fixes placement new. (Sebastian, please review).

llvm-svn: 72673

llvm-svn: 72672