No need for 'getOperand' :)

llvm-svn: 148778

llvm-svn: 148777

llvm-svn: 148776

llvm-svn: 148775

llvm-svn: 148774

llvm-svn: 148772

Add comments near load pattern fragments indicating that all integer vector loads are promoted to v2i64 or v4i64 so that no one tries to reintroduce pattern fragments for other types.

llvm-svn: 148771

llvm-svn: 148770

llvm-svn: 148769

llvm-svn: 148768

the tests are making assertions about the name of the clang binary, so
we should ensure that the name is as stable as possible.

llvm-svn: 148767

to find the possible session directories with names starting with %Y-%m-%d- (for example,
2012-01-23-) and employs the one with the latest timestamp.  For example:

johnny:/Volumes/data/lldb/svn/latest/test $ ./redo.py 
Using session dir path: /Volumes/data/lldb/svn/latest/test/2012-01-23-11_28_30
adding filterspec: DisassembleRawDataTestCase.test_disassemble_raw_data
Running ./dotest.py  -C clang  -v -t -f DisassembleRawDataTestCase.test_disassemble_raw_data
LLDB build dir: /Volumes/data/lldb/svn/latest/build/Debug
LLDB-108
Path: /Volumes/data/lldb/svn/latest
URL: https://johnny@llvm.org/svn/llvm-project/lldb/trunk
Repository Root: https://johnny@llvm.org/svn/llvm-project
Repository UUID: 91177308-0d34-0410-b5e6-96231b3b80d8
Revision: 148710
Node Kind: directory
Schedule: normal
Last Changed Author: gclayton
Last Changed Rev: 148650
Last Changed Date: 2012-01-21 18:55:08 -0800 (Sat, 21 Jan 2012)



Session logs for test failures/errors/unexpected successes will go into directory '2012-01-23-17_04_48'
Command invoked: python ./dotest.py -C clang -v -t -f DisassembleRawDataTestCase.test_disassemble_raw_data

Configuration:  compiler=clang
----------------------------------------------------------------------
Collected 1 test

Change dir to: /Volumes/data/lldb/svn/latest/test/python_api/disassemble-raw-data
1: test_disassemble_raw_data (TestDisassembleRawData.DisassembleRawDataTestCase)
   Test disassembling raw bytes with the API. ... 
Raw bytes:    ['0x48', '0x89', '0xe5']
Disassembled: movq   %rsp, %rbp
ok
Restore dir to: /Volumes/data/lldb/svn/latest/test

----------------------------------------------------------------------
Ran 1 test in 0.233s

OK

llvm-svn: 148766

llvm-svn: 148765

llvm-svn: 148764

llvm-svn: 148763

llvm-svn: 148762

llvm-svn: 148761

matches a typedef declaring an object type. // rdar://10733000

llvm-svn: 148760

violation -- MC cannot depend on CodeGen.

Specifically, the MCTargetDesc component of each target is actually
a subcomponent of the MC library. As such, it cannot depend on the
target-independent code generator, because MC itself cannot depend on
the target-independent code generator. This change moved a flag from the
ARM MCTargetDesc file ARMMCAsmInfo.cpp to the CodeGen layer in
ARMException.cpp, leaving behind an 'extern' to refer back to it. That
layering order isn't viable givin the constraints outlined above.
Commandline flags are designed to be static specifically to avoid these
types of bugs.

Fixing this is likely going to require some non-trivial refactoring.

llvm-svn: 148759

llvm-svn: 148757

llvm-svn: 148756

llvm-svn: 148755

llvm-svn: 148754

type of pointers. 

llvm-svn: 148753

I renamed abort_message to be a C++ file to simplify my simplistic build script which I'm still working on.  I also added a struct for the crash reporter on __APPLE__.

llvm-svn: 148752

llvm-svn: 148751

A lot of the code in cxa_exception.cpp depends on __cxa_get_globals_fast() returning null if __cxa_get_globals() hasn't been called yet.  However it doesn't reliably do that, at least on OS X if __cxa_get_globals_fast() is called prior to pthread_key_create() running.  Our choice is to either limit our use of __cxa_get_globals_fast() more than we have, or to have __cxa_get_globals_fast() initialize with pthread_key_create() if necessary.  I chose the latter, and replaced pthread_once with a C++11 local static (which should do the same thing).

llvm-svn: 148750

llvm-svn: 148749

llvm-svn: 148748

its line. // rdar://10711037

llvm-svn: 148747

This was suggested by Chandler Carruth on the basis of past experience with
esoteric compilers/quirks relating to signed enums.

llvm-svn: 148746

llvm-svn: 148745

llvm-svn: 148744

llvm-svn: 148743

llvm-svn: 148742

classes, per PR1324.  Not all of their helper functions are implemented,
nothing creates them, and the rest of the compiler doesn't handle them yet.

llvm-svn: 148741

llvm-svn: 148740

llvm-svn: 148739

llvm-svn: 148738

llvm-svn: 148737