llvm-svn: 146522

llvm-svn: 146521

rdar://10549767

llvm-svn: 146520

rdar://10550269

llvm-svn: 146519

rdar://10549786

llvm-svn: 146518

llvm-svn: 146517

llvm-svn: 146516

rdar://10549741

llvm-svn: 146515

llvm-svn: 146514

llvm-svn: 146511

llvm-svn: 146508

llvm-svn: 146507

llvm-svn: 146505

in classes. // rdar://10535349

llvm-svn: 146504

llvm-svn: 146503

load and then move the result from a GPR to a FPR.

llvm-svn: 146502

llvm-svn: 146501

build compiler-rt with -fPIC, otherwise the run-time libs will not link with -pie, at least on linux

llvm-svn: 146499

rdar://10573361

llvm-svn: 146498

rdar://10567864&10567916

llvm-svn: 146497

@class forward references.

rdar://10568080&10568103&10568119

llvm-svn: 146496

llvm-svn: 146493

instructions that define aggregate types.

llvm-svn: 146492

llvm-svn: 146487

llvm-svn: 146486

llvm-svn: 146485

llvm-svn: 146484

Tweak ARC diagnostic categories and rename 'Automatic Reference Counting Issue' to 'ARC Parse Issue' and 'ARC Issue' to 'ARC Semantic Issue'.  Patch by Jean-Daniel Dupas.

llvm-svn: 146483

Added an assertion about overflow in sizeof evaluation. This does not solve the underlying structural issue that is waiting for a proper solution.

llvm-svn: 146482

Fast ISel isn't able to handle 'insertvalue' and it causes a large slowdown
during -O0 compilation. We don't necessarily need to generate an aggregate of
the values here if they're just going to be extracted directly afterwards.
<rdar://problem/10530851>

llvm-svn: 146481

llvm-svn: 146480

be constant expressions.

llvm-svn: 146479

Check that the pc value for frames up the stack is in a
mapped+executable region of memory.

Check that the stack pointer for frames up the stack is
in a mapped+readable region of memory.

If the unwinder ever makes a mistake walking the stack,
these checks will help to keep it from going too far into
the weeds.

These aren't fixing any bugs that I know of, but they
add extra robustness to a complicated task.

llvm-svn: 146478

if this is a mapped/executable region of memory.  If it isn't, we've jumped
through a bad pointer and we know how to unwind the stack correctly based
on the ABI.  

Previously I had 0x0 special cased but if you jumped to 0x2 on x86_64 one
frame would be skipped because the unwinder would try using the x86_64 
ArchDefaultUnwindPlan which relied on the rbp.

Fixes <rdar://problem/10508291>

llvm-svn: 146477

llvm-svn: 146476

DW_FORM_flag. Use DW_FORM_data1 for one byte.

llvm-svn: 146475

I'm not sure I have this right but it looks correct.

llvm-svn: 146474

parse.

llvm-svn: 146473

llvm-svn: 146472

having the block, then timing out & letting all threads run actually works.

llvm-svn: 146471