Dynamic, Initial Exec and Local Exec TLS models.

Patch by Sasa Stankovic

llvm-svn: 132322

llvm-svn: 132321

llvm-svn: 132320

llvm-svn: 132319

directives.

Fixes PR9826.

llvm-svn: 132317

rdar://problem/6501862

llvm-svn: 132316

llvm-svn: 132315

same dwarf number. This will be used for creating a dwarf number to register
mapping.

The only case that needs this so far is the XMM/YMM registers that unfortunately
do have the same numbers.

llvm-svn: 132314

subregisters of the 64 bit ones.

llvm-svn: 132313

and for now the generic dwarf emission will automatically use the superregister
numbers.

llvm-svn: 132312

llvm-svn: 132311

llvm-svn: 132310

llvm-svn: 132309

llvm-svn: 132308

forwarding of eh.resume that I promised yesterday.

llvm-svn: 132307

llvm-svn: 132304

they don't update correctly. Currently if a variable is unavailable due to
a register not being available in a higher frame or due to the PC value
not being a valid location list value, "<unknown type>" will get displayed
as the variable type. I am not sure what other things will fail, so I am 
disabling it for now just by letting the default enumeration value default
to it being disabled.

llvm-svn: 132303

handler's data area starts with a 4-byte reference to the personality
function, followed by the DWARF LSDA.

llvm-svn: 132302

llvm-svn: 132301

to stdout. This helps identifying missing coverage on a given platform.

llvm-svn: 132300

This commit seems to have broken a darwin 9 tester.

llvm-svn: 132299

This only affects targets like Mips where branch instructions may kill virtual
registers. Most other targets branch on flag values, so virtual registers are
not involved.

The problem is that MachineBasicBlock::updateTerminator deletes branches and
inserts new ones while LiveVariables keeps a list of pointers to instructions
that kill virtual registers. That list wasn't properly updated in
MBB::SplitCriticalEdge.

llvm-svn: 132298

This path was reviewed by Chandler Carruth at http://codereview.appspot.com/4538074/

llvm-svn: 132297

llvm-svn: 132296

This is important for the correct lowering of unwind instructions
(which doesn't matter at all) and llvm.eh.resume calls (which does).

Take 2, now with more basic competence.

llvm-svn: 132295

llvm-svn: 132294

llvm-svn: 132293

doing llvm-gcc selfhost (or cross).

llvm-svn: 132292

This is important for the correct lowering of unwind instructions
(which doesn't matter at all) and llvm.eh.resume calls (which does).

llvm-svn: 132291

llvm-svn: 132290

its definition, that the first enumeration doesn't always get used as the
default.

llvm-svn: 132289

variable. Noticed by inspection.

Simulate memset in EvaluateFunction where the target of the memset and the
value we're setting are both the null value. Fixes PR10047!

llvm-svn: 132288

llvm-svn: 132287

llvm-svn: 132286

llvm-svn: 132285

I tried to use an assert to prove that I could remove each of the
arguments I did, but ended up writing my assert with inverted logic.
Doh! Reported by Xi Wang on cfe-dev. I have manually verified the source
locations and ranges for these using -ast-dump. I tried writing a test
case that would catch these, but these expressions aren't exposed in the
c-index-test's token annotation utility.

llvm-svn: 132284

handler.

At this moment, only GCC-style exceptions are supported. Other kinds
of exceptions, including "traditional" SEH and Microsoft Visual C++ exceptions,
need more work--and an compiler exception model that isn't specific to
GCC-style exceptions!

In particular, I imagine that it would be possible to mix "traditional" SEH
with GCC-style EH or Microsoft C++ EH. Currently LLVM has no way (beyond some
target-specific defaults and whole-module compiler switches) of knowing which
scheme to use when.

llvm-svn: 132283

llvm-svn: 132281

(or anything running in a terminal) wants. Not what a UI (Xcode) would want 
where it creates a debugger per debug window. The current code had an infinite
loop after a debug session ended. 

llvm-svn: 132280

llvm-svn: 132279