llvm-svn: 100532

A certain GDB testsuite case (local.cc) has a function nested inside a
class nested inside another function.  GCC presents the innermost
function to llvm-convert first.  Heretofore, the debug info mistakenly
placed the inner function at module scope.  This patch walks the GCC
context links and instantiates the outer class and function so the
debug info is properly nested.  Radar 7426545.

llvm-svn: 100530

llvm-svn: 100525

llvm-svn: 100521

use case where someone wants to resurrect LLVM after calling llvm_shutdown,
but I'm not aware of any clients that are affected by this.

llvm-svn: 100519

Overflowing an unsigned integer is fine and behaves as you would expect.
Also fix a pasto, allowing SignExtend64 to take a 64-bit argument.

llvm-svn: 100517

llvm-svn: 100515

llvm-svn: 100510

llvm-svn: 100509

llvm-svn: 100508

llvm-svn: 100506

llvm-svn: 100505

llvm-svn: 100504

diagnostic handler.

llvm-svn: 100503

llvm-svn: 100499

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

llvm-svn: 100497

llvm-svn: 100494

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: 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: 100468

llvm-svn: 100467

llvm-svn: 100466

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: 100461

llvm-svn: 100459

PR6779

llvm-svn: 100457

llvm-svn: 100455

in Dominators.

llvm-svn: 100454

llvm-svn: 100447

isn't well specified.  ARM really needs to have its instprinter
finished at some point.

llvm-svn: 100439

llvm-svn: 100438

with spaces in them.  Sym->getName()  !=   OS << *Sym

llvm-svn: 100434