Including following 14 instructions:
4 ld1 insts: load multiple 1-element structure to sequential 1/2/3/4 registers.
ld2/ld3/ld4: load multiple N-element structure to sequential N registers (N=2,3,4).
4 st1 insts: store multiple 1-element structure from sequential 1/2/3/4 registers.
st2/st3/st4: store multiple N-element structure from sequential N registers (N = 2,3,4).

llvm-svn: 192352

Including following 14 instructions:
4 ld1 insts: load multiple 1-element structure to sequential 1/2/3/4 registers.
ld2/ld3/ld4: load multiple N-element structure to sequential N registers (N=2,3,4).
4 st1 insts: store multiple 1-element structure from sequential 1/2/3/4 registers.
st2/st3/st4: store multiple N-element structure from sequential N registers (N = 2,3,4).

E.g. ld1(3 registers version) will load 32-bit elements {A, B, C, D, E, F} sequentially into the three 64-bit vectors list {BA, DC, FE}.
E.g. ld3 will load 32-bit elements {A, B, C, D, E, F} into the three 64-bit vectors list {DA, EB, FC}.

llvm-svn: 192351

llvm-svn: 192350

Summary: Colon was incorrectly detected as a start of inheritance list. Fixed.

Reviewers: djasper

Reviewed By: djasper

CC: cfe-commits, klimek

Differential Revision: http://llvm-reviews.chandlerc.com/D1884

llvm-svn: 192349

llvm-svn: 192348

Use the existing convenience function.

llvm-svn: 192347

Emit a proper error instead of crashing in CodeGen. PR16892.

llvm-svn: 192345

When we had a sequence like:

    s1 = VLDRS [r0, 1], Q0<imp-def>
    s3 = VLDRS [r0, 2], Q0<imp-use,kill>, Q0<imp-def>
    s0 = VLDRS [r0, 0], Q0<imp-use,kill>, Q0<imp-def>
    s2 = VLDRS [r0, 4], Q0<imp-use,kill>, Q0<imp-def>

we were gathering the {s0, s1} loads below the s3 load. This is fine,
but confused the verifier since now the s3 load had Q0<imp-use> with
no definition above it.

This should mark such uses <undef> as well. The liveness structure at
the beginning and end of the block is unaffected, and the true sN
definitions should prevent any dodgy reorderings being introduced
elsewhere.

rdar://problem/15124449

llvm-svn: 192344

The patch reviewed by Rafael Espindola.
http://llvm-reviews.chandlerc.com/D1843

llvm-svn: 192343

-- so that command line options to specify new input files, such as
/defaultlib:foo, is handled properly. Such options were ignored before
this patch.

llvm-svn: 192342

llvm-svn: 192341

llvm-svn: 192340

llvm-svn: 192339

llvm-svn: 192338

Differential Revision: http://llvm-reviews.chandlerc.com/D1881

llvm-svn: 192337

Based on the POSIX x86_64 register context.  This is sufficient for opening
a mips64 (big endian) core file.  Subsequent changes will connect the
disassembler, dynamic loader support, ABI, etc.

Review: http://llvm-reviews.chandlerc.com/D1873

(Missed "svn add" on this file in r192335)

llvm-svn: 192336

Based on the POSIX x86_64 register context.  This is sufficient for opening
a mips64 (big endian) core file.  Subsequent changes will connect the
disassembler, dynamic loader support, ABI, etc.

Review: http://llvm-reviews.chandlerc.com/D1873
llvm-svn: 192335

Fix getIntegerTypeOrder() to properly handle enums by first unwrapping their underlying integer type.  This is a precondition for calling getIntegerRank().

Fixes an assertion failure in a test case involving vectors.

Fixes <rdar://problem/15091442>

Please somebody check this.

llvm-svn: 192334

made sure we don't keep around no-longer-valid
ASTTransformers.

<rdar://problem/15182379>

llvm-svn: 192333

llvm-svn: 192332

This exposes a 32-bit view of the registry even when Clang is built as a 64-bit
program. Since Visual Studio is a 32-bit application, this is necessary for us
to find it.

llvm-svn: 192331

ins/ext.

llvm-svn: 192330

This reverts commit r192316. The original change introduced circular
dependencies between libTarget and backends. That would broke a build unless
link everything into one big binary.

llvm-svn: 192329

Refine string literal concatenation warning within an NSArray literal to not warn when the literal comes from a macro expansion.  Fixes <rdar://problem/15147688>.

llvm-svn: 192328

importer to avoid duplicate imports of anonymous
structs.

<rdar://problem/14421722>

llvm-svn: 192327

LLDB (Terminal) User Interface
==============================
This directory contains the curses user interface for LLDB. To use it, ensure Python can find your lldb module. You may have to modify PYTHONPATH for that purpose:

$ export PYTHONPATH=/path/to/lldb/module

Then, run the lui.py. To load a core file:
$ ./lui.py --core core

To create a target from an executable:
$ ./lui.py /bin/echo "hello world"

To attach to a running process:
$ ./lui.py --attach <pid>


Known Issues
============
1. Resizing the terminal will most likely cause lui to crash.
2. Missing paging in command-window
3. Only minimal testing (on Ubuntu Linux x86_64)

Missing Features
================
- stdin/stdout/stderr windows
- memory window
- backtrace window
- threads window
- tab-completion
- syntax-highlighting (via pygments library)
- (local) variables window
- registers window
- disassembly window
- custom layout

llvm-svn: 192326

llvm-svn: 192325

ASTImporter when importing the following types:

typedef struct {
} A;

typedef struct {
  A a;
} B;

Suppose we have imported B, but we did not at that
time need to complete it.  Then later we want to
import A.  The struct is anonymous, so the first
thing we want to do is make sure no other anonymous
struct already matches it.  So we set up an
StructuralEquivalenceContext and compare B with A.

This happens at ASTImporter.cpp:2179.

Now, in this scenario, B is not complete.  So we go
and import its fields, including a, which causes A
to be imported.  The ASTImporter doesn’t yet have A
in its list of already-imported things, so we
import A.

After the StructuralEquivalenceContext is finished
determining that A and B are different, the
ASTImporter concludes that A must be imported
because no equivalent exists, so it imports a second
copy of A.  Now we have two different structs
representing A.  This is really bad news.

The patch allows the StructuralEquivalenceContext to
use the original version of B when making its
comparison, obviating the need for an import and
cutting this loop.

llvm-svn: 192324

ObjectFile::CopyData is used to copy a block of target memory to the
caller's buffer (e.g. for "memory read").  This should be a straight
memcpy, and not byte-swapped if the target and host have different
endianness.

Add a new DataExtractor::CopyData() method that performs this straight
copy and use it in ObjectFile::CopyData().

llvm-svn: 192323

llvm-svn: 192322

template_type and template_value are updated to use DIRef.

Paired commit with r192320.

llvm-svn: 192321

template_value are updated to use DIRef.

A paired commit at clang is required due to changes to DIBuilder.

llvm-svn: 192320

llvm-svn: 192319

llvm-svn: 192318

and use it to infer all properties as 'atomic'.
// rdar://14988132

llvm-svn: 192317

Making them proper functions defined in the (shared)lib instead of
static inlines defined in the header files makes it possible to
actually distribute a binary compiled against the shared library
without having to worry about getting undefined symbol errors when
calling e.g LLVMInitializeAllTargetInfos because the shared library on
the other system was compiled with different targets.

Differential Revision: http://llvm-reviews.chandlerc.com/D1714

llvm-svn: 192316

llvm-svn: 192315

marked all variables as "unknown" at the start of a loop.  The new version
keeps the initial state of variables unchanged, but issues a warning if the
state at the end of the loop is different from the state at the beginning.
This patch will eventually be replaced with a more precise analysis.

Initial patch by chris.wailes@gmail.com.  Reviewed and edited by
delesley@google.com.

llvm-svn: 192314

llvm-svn: 192313

Reviewed at http://llvm-reviews.chandlerc.com/D1867

llvm-svn: 192312