llvm-svn: 127697

On Win32 console, emitting char to col#79 causes linefeed, and the cursor will not return to col#79 upper line with backspace.

llvm-svn: 127696

up AVX disassembly support.

llvm-svn: 127695

llvm-svn: 127694

llvm-svn: 127693

llvm-svn: 127692

llvm-svn: 127691

llvm-svn: 127688

llvm-svn: 127687

build lldb, LLDB.framework and debugserver all with just DWARF (no dSYM).

llvm-svn: 127686

llvm-svn: 127685

llvm-svn: 127684

llvm-svn: 127683

declaration as this results in a confusing error message,
instead of message related to missing property declaration.
// rdar://9106929

llvm-svn: 127682

llvm-svn: 127681

llvm-svn: 127680

Without this cmake fails at configuration when some target pass
"native" on LLVM_LINK_COMPONENTS and that is expanded to "X86".

llvm-svn: 127679

llvm-svn: 127678

- Remove PTX 1.4 code generation
- Change type of intrinsics to .v4.i32 instead of .v4.i16
- Add and/or/xor integer instructions

llvm-svn: 127677

MCFixupKind.  This is the same technique that is used elsewhere in MC.

llvm-svn: 127676

when building with assertions disabled.

llvm-svn: 127675

llvm-svn: 127674

memory builtins as equivalent to malloc/free.

This is different from any attribute we have. For example, you can delete the
allocators when their result is unused, but you can't collapse two calls to the
same function, even if no global/memory state has changed in between. The
noalias return states that the result does not alias any other pointer, but
instcombine optimizes malloc() as though the result is non-null for the purpose
of eliminating unused pointers.

llvm-svn: 127673

llvm-svn: 127672

llvm-svn: 127671

Take 2: merge -Wuninitialized-experimental into -Wuninitialized.  Only *must-be-uninitialized* warnings are reported, with *maybe-uninitialized* under a separate flag.  I await any fallout/comments/feedback, although hopefully this will produce no noise for users.

llvm-svn: 127670

Split warnings from -Wuninitialized-experimental into "must-be-initialized" and "may-be-initialized" warnings, each controlled by different flags.

llvm-svn: 127669

v2 = bitcast v1
...
v3 = bitcast v2
...
   = v3
=>
v2 = bitcast v1
...
   = v1
if v1 and v3 are of in the same register class.

bitcast between i32 and fp (and others) are often not nops since they
are in different register classes. These bitcast instructions are often
left because they are in different basic blocks and cannot be
eliminated by dag combine.

rdar://9104514

llvm-svn: 127668

nothing more than a bitcast.
- Teach tablegen to automatically infer "Bitcast" property.

llvm-svn: 127667

Split warnings from -Wuninitialized-experimental into "must-be-initialized" and "may-be-initialized" warnings, each controlled by different flags.

llvm-svn: 127666

UninitializedValues: introduce ValueVector:reference class to forward to llvm::BitVector.  No real functionality change, but this is a stepping stone to moving to tri-state logic.

llvm-svn: 127665

UninitializedValues: wrap BitVector references in a new class ValueVector.  No functionality change.  This defines the minimum interface that ValueVector needs to support when we no longer base it strictly on a direct interpretation of BitVector.

llvm-svn: 127664

Substitue term "BitVector" with "ValueVector" to prep for further revisions.  No functionality change.

llvm-svn: 127663

for templatized types that could cause parts of a std::vector (and I am sure
other STL types) to be incorrectly uniqued to each other wreaking havoc on 
variable display for types within the same executable module.

llvm-svn: 127662

easier since "short" ends up with "short int" in the template allocators.

llvm-svn: 127661

types that have different contents. Currently LLDB is incorrectly uniquing,
on MacOSX, the std::vector _VectorImpl class from the two different vector
templates. The DWARF looks like:

0x0000008e:         DW_TAG_structure_type [7] *
                     DW_AT_name( "_Vector_base<int,std::allocator<int> >" )
                     DW_AT_declaration( 0x01 )
                     DW_AT_sibling( {0x00000103} )

0x00000098:             DW_TAG_structure_type [8] *
                         DW_AT_name( "_Vector_impl" )
                         DW_AT_byte_size( 0x18 )
                         DW_AT_decl_file( "/usr/include/c++/4.2.1/bits/stl_vector.h" )
                         DW_AT_decl_line( 83 )

0x000000a0:                 DW_TAG_inheritance [9]  
                             DW_AT_type( {0x000006fa} ( allocator<int> ) )
                             DW_AT_data_member_location( +0 )
                             DW_AT_accessibility( DW_ACCESS_public )



0x0000011b:         DW_TAG_structure_type [7] *
                     DW_AT_name( "_Vector_base<short int,std::allocator<short int> >" )
                     DW_AT_declaration( 0x01 )
                     DW_AT_sibling( {0x00000190} )

0x00000125:             DW_TAG_structure_type [8] *
                         DW_AT_name( "_Vector_impl" )
                         DW_AT_byte_size( 0x18 )
                         DW_AT_decl_file( "/usr/include/c++/4.2.1/bits/stl_vector.h" )
                         DW_AT_decl_line( 83 )

0x0000012d:                 DW_TAG_inheritance [9]  
                             DW_AT_type( {0x00000f75} ( allocator<short int> ) )
                             DW_AT_data_member_location( +0 )
                             DW_AT_accessibility( DW_ACCESS_public )


In this case it using DIE 0x00000098 for both 0x00000098 and 0x00000125.

This test will help detect this issue once I have a fix for it. I have a fix
that I am testing.

llvm-svn: 127660

llvm-svn: 127659

llvm-svn: 127657

llvm-svn: 127656

lib/Basic/Targets.cpp: __declspec(attr) should be provided on mingw as macro, alias of __attribute__.

On mingw without -fms-extensions, we can provide "as-is" __declspec.

llvm-svn: 127655