can asmprint:

NEW: 	movl	"L___stack_chk_guard$non_lazy_ptr", %eax
OLD: 	movl	L___stack_chk_guard$non_lazy_ptr, %eax

where 'new' is coming out of the MCInst version of the printer.

llvm-svn: 79170

llvm-svn: 79168

llvm-svn: 79167

llvm-svn: 79166

llvm-svn: 79165

CHECK-NEXT is on.

llvm-svn: 79164

llvm-svn: 79163

llvm-svn: 79162

llvm-svn: 79161

llvm-svn: 79160

llvm-svn: 79159

llvm-svn: 79158

Move builtin call checking out into a separate function, make CheckFunctionCall and CheckBlockCall return bool instead. No intended functionality change.

llvm-svn: 79157

llvm-svn: 79156

llvm-svn: 79150

llvm-svn: 79149

initializes all the members; this fixes a valgrind error in the 
regression tests.

llvm-svn: 79148

llvm-svn: 79147

llvm-svn: 79146

llvm-svn: 79145

llvm-svn: 79144

llvm-svn: 79143

llvm-svn: 79142

llvm-svn: 79140

what was there before. In "no FP mode", we weren't generating labels and unwind
table entries after each "push" instruction. While more than likely "okay", it's
not technically correct. The major thing was that the ordering of when to define
a new CFA register and at what offset wasn't correct. This would cause the
exception handling to fail in ways most miserable to users.

I also cleaned up some code a bit. There's one function which has a "return" at
the beginning, so it's never used. Should I just remove it? :-)

llvm-svn: 79139

llvm-svn: 79138

llvm-svn: 79136

llvm-svn: 79135

llvm-svn: 79134

llvm-svn: 79133

blocks.

llvm-svn: 79132

llvm-svn: 79131

llvm-svn: 79130

llvm-svn: 79128

support unaligned mem access only for certain types. (Should it be size
instead?)

ARM v7 supports unaligned access for i16 and i32, some v6 variants support it
as well.

llvm-svn: 79127

simplifies the AST, and can matter in some rare cases involving 
casts to vector types. Patch by Enea Zaffanella.

llvm-svn: 79126

constructor body whose class has non-static data-members which
required non-trivial construction.

llvm-svn: 79125

llvm-svn: 79124

llvm-svn: 79123

It is legal for an inline asm operand to use an earlyclobber register if the
use operand is tied to the earlyclobber operand. The issue is discussed here:

  http://gcc.gnu.org/ml/gcc/1999-04n/msg00431.html

We should perhaps let only the machine code verifier worry about these finer
details. EarlyClobber operands are not really interesting to the scavenger.

This fixes PR4528 for the third time.

llvm-svn: 79122