llvm-svn: 100509

llvm-svn: 100508

llvm-svn: 100506

llvm-svn: 100505

llvm-svn: 100504

diagnostic handler.

llvm-svn: 100503

llvm-svn: 100499

maybe-ownership vs. ownership.

llvm-svn: 100498

Operand 2 on a load instruction does not have to be a RegisterSDNode for this to
work.

llvm-svn: 100497

llvm-svn: 100496

llvm-svn: 100494

works with inline asm!

llvm-svn: 100493

the stream.  New demo:

$ clang asm.c -S -o - -emit-llvm | llc -filetype=obj -o t.o
$ otool -tv t.o
t.o:
(__TEXT,__text) section
_foo:
0000000000000000	subq	$0x08,%rsp
0000000000000004	movl	%edi,(%rsp)
0000000000000007	movl	%edi,%eax
0000000000000009	incl	%eax
000000000000000b	movl	%eax,(%rsp)
000000000000000e	movl	%eax,0x04(%rsp)
0000000000000012	addq	$0x08,%rsp
0000000000000016	ret

llvm-svn: 100492

demo:

$ clang asm.c -S -o - -emit-llvm | llc -filetype=obj -o t.o
<inline asm>:1:2: error: unrecognized instruction
	abc incl    %eax
	^
LLVM ERROR: Error parsing inline asm

Only problem seems to be that the parser finalizes OutStreamer 
at the end of the first inline asm, which isn't what we want.
For example:

$ cat asm.c
int foo(int X) {
 __asm__ ("incl    %0" : "+r" (X));
 return X;
}
$ clang asm.c -S -o - -emit-llvm | llc
...
	subq	$8, %rsp
	movl	%edi, (%rsp)
	movl	%edi, %eax
	## InlineAsm Start
	incl    %eax
	## InlineAsm End
	movl	%eax, (%rsp)
	movl	%eax, 4(%rsp)
	addq	$8, %rsp
	ret
$ clang asm.c -S -o - -emit-llvm | llc -filetype=obj -o t.o
$ otool -tv t.o
t.o:
(__TEXT,__text) section
_foo:
0000000000000000	subq	$0x08,%rsp
0000000000000004	movl	%edi,(%rsp)
0000000000000007	movl	%edi,%eax
0000000000000009	incl	%eax
$ 

don't stop at inc!

llvm-svn: 100491

llvm-svn: 100490

llvm-svn: 100489

the FP encoding directly as a hex representation.

llvm-svn: 100487

llvm-svn: 100486

a co-committed clang patch.

llvm-svn: 100485

llvm-svn: 100484

Fix possible null dereference by bailing out of CheckObjCPropertyAttributes() early if the Decl* is null.

llvm-svn: 100483

llvm-svn: 100482

llvm-svn: 100480

undefs in branches/switches, we have two cases: a branch on a literal
undef or a branch on a symbolic value which is undef.  If we have a
literal undef, the code was correct: forcing it to a constant is the
right thing to do.

If we have a branch on a symbolic value that is undef, we should force
the symbolic value to a constant, which then makes the successor block
live.  Forcing the condition of the branch to being a constant isn't 
safe if later paths become live and the value becomes overdefined.  This
is the case that 'forcedconstant' is designed to handle, so just use it.

This fixes rdar://7765019 but there is no good testcase for this, the
one I have is too insane to be useful in the future.

llvm-svn: 100478

llvm-svn: 100476

llvm-svn: 100475

 - Unfortunately, this requires some horrible code in CGObjCMac which always
   allocats a CGBitFieldInfo because we don't currently build a proper layout
   for Objective-C classes. It needs to be cleaned up, but I don't want the
   bit-field cleanups to be blocked on that.

llvm-svn: 100474

of file locations for anonymous tag types (e.g., "enum <anonymous at
t.h:15:6>"), which can get rather long.

llvm-svn: 100470

failing test files.

llvm-svn: 100469

llvm-svn: 100468

llvm-svn: 100467

llvm-svn: 100466

ASTUnit. Previously, we would end up with use-after-free errors
because the Diagnostic object would be creating in one place (say,
CIndex) and its ownership would not be transferred into the
ASTUnit. Fixes <rdar://problem/7818608>.

llvm-svn: 100464

ownership over the pointer it contains. Useful when we want to
communicate ownership while still having several clients holding on to
the same pointer *without* introducing reference counting.

llvm-svn: 100463

llvm-svn: 100462

llvm-svn: 100461

llvm-svn: 100459

PR6779

llvm-svn: 100457

llvm-svn: 100455

in Dominators.

llvm-svn: 100454