We were just emitting a label for this section for no real reason - this
caused us to emit the section even though we never put anything in it.

Not bothering with a test (though not adamantly anti-test) because it
seems somewhat arbitrary to test for the absence of this section anymore
than the absence of any other section.

llvm-svn: 201876

Improved the GDBRemoteCommunicationClient::TestPacketSpeed() function so it tests how long it takes to send a 4MB buffer from the REMOTE GDB server to LLDB.

llvm-svn: 201875

llvm-svn: 201874

llvm-svn: 201873

Previously the lldb-platform and lldb-gdbserver would crash.

llvm-svn: 201872

spotting this!

llvm-svn: 201871

llvm-svn: 201870

llvm-svn: 201869

handle special cases Step==1, Step==-1, GCD==1, and GCD==-1

llvm-svn: 201868

in the dependence test, we used to discard some information that the
delinearization provides: the size of the innermost dimension of an array,
i.e., the size of scalars stored in the array, and the remainder of the
delinearization that provides the offset from which the array reads start,
i.e., the base address of the array.

To avoid losing this data in the rest of the data dependence analysis, the fix
is to multiply the access function in the last delinearized dimension by its
size, effectively making the size of the last dimension to always be in bytes,
and then add the remainder of delinearization to the last subscript,
effectively making the last subscript start at the base address of the array.

llvm-svn: 201867

Because the delinearization is not a global analysis pass, it will compute the
delinearization independently of knowledge about the way the delinearization
happened for other data accesses to the same array: the dependence analysis will
only trigger the delinearization on a tuple of access functions, and thus
delinearization may compute different subscripts sizes for a same array.  When
that happens the safest is to discard the delinearized information.

llvm-svn: 201866

llvm-svn: 201865

Fix historical #ifdef. Use __cplusplus instead of __GXX_EXPERIMENTAL_CXX0X__ when compiling with clang. No functionality change.

llvm-svn: 201864

llvm-svn: 201863

llvm-svn: 201862

[tsan] add coarse-grained lock around the DeadlockDetector. We can do better than that, but that's a start.

llvm-svn: 201861

We now skip the debug intrinsics which is a lot better than crashing due to
uncopied metadata references. We should step by step investigate which debug
intrinsics we can copy without trouble.

We still keep the debug location metadata.

llvm-svn: 201860

llvm-svn: 201859

llvm-svn: 201858

llvm-svn: 201857

llvm-svn: 201856

http://www.cmake.org/Bug/view.php?id=14747

llvm-svn: 201855

[CMake] Introduce "llvm_add_library(SHARED STATIC)" to build both shared lib and static lib simulataneously.

  llvm_add_library(foo SHARED STATIC
    DEPENDS <dependent targets...>
    LINK_LIBS <required libraries...>
    )

It generates both foo (foo.so) and foo_static(foo.a) and both of them depend on DEPENDS and LINK_LIBS.
Then, also obj.foo is generated. obj.foo depends on DEPENDS, but doesn't depend on LINK_LIBS.

llvm-svn: 201854

The module still needs to collect the list of all available libraries
in order to satisfy the 'all' component.  Provide this in the package
configuration file, 'LLVMConfig.cmake', as a LLVM_AVAILABLE_LIBS
variable.  (A variable is scoped better than a global property.)
Since this won't be set for our own build, fall back to looking up the
LLVM_LIBS property to get the value when it is not set.

Contributed by Brad King.

llvm-svn: 201853

LLVM library names are now available as logical CMake targets both
to our own build and to application CMake code.  Replace use of
'list(FIND)' with a simple 'if(TARGET)' to determine whether a
library is available.

Contributed by Brad King.

llvm-svn: 201852

Moving the documentation for the type safety checking attributes into AttrDocs. If a custom heading is provided, do not automatically generate the alternate spelling list. This is necessary because some attributes have distinct semantic spellings and meanings, but use the same semantic attribute internally. Such attributes should have multiple elements in their documentation list, but not show all spellings. At some point, it would be nice to have a way to attach the documentation element to a specific spelling for these cases.

llvm-svn: 201851

llvm-svn: 201850

llvm-svn: 201849

This extends the intrinsic lookup table format slightly, and adds
entries for use the shared ARM/AArch64 definitions. The benefit is
currently smaller than for the SISD intrinsics (there's more custom
code implementing this set), but a few lines are saved and there's
scope for future expansion.

llvm-svn: 201848

This extracts the table-driven intrinsic lookup phase into a separate
function, to be used by EmitCommonNeonBuiltinExpr soon.

It also simplifies the logic used in that lookup, since VectorCastArgN
and ScalarArgN were actually identical.

llvm-svn: 201847

Added two new options for -mfpu when targetting ARM:
* fpv4-sp-d16
* fp4-sp-d16

The first is the same spelling as gcc.

The lack of a leading `v' is correct, this is consistent with ARM's
documentation and gcc's spelling of the option.

llvm-svn: 201846

When actually compiling we use clang for the final .dylib creation stage, so we
should ask it what linker it'll use when detecting support for our
architectures.

llvm-svn: 201845

Error 1 error C2681: 'add_rvalue_reference<_Tp*>::type' : invalid expression
type for dynamic_cast c:\libcxx\include\type_traits

This is one more step getting libcxx compile under Visual C++. The patch is 
#if defined(_LIBCPP_MSVC) so will affect only this build.

When libcxx can be compiled, it will probably require the current version or
maybe even the next Update of Visual C++ 2013.

Patch by G M!

llvm-svn: 201844

rather than its own type for std::max_align_t. This is particularly
relevant as the types may not be ABI compatible despite users expecting
them to be.

llvm-svn: 201843

[CMake] Get rid of explicit dependencies to include/clang/*.inc and introduce CLANG_TABLEGEN_TARGETS.

This does;
  - clang_tablegen() adds each tblgen'd target to global property CLANG_TABLEGEN_TARGETS as list.
  - List of targets is added to LLVM_COMMON_DEPENDS.
  - all clang libraries and targets depend on generated headers.

You might wonder this would be regression, but in fact, this is little loss.
  - Almost all of clang libraries depend on tblgen'd files and clang-tblgen.
  - clang-tblgen may cause short stall-out but doesn't cause unconditional rebuild.
  - Each library's dependencies to tblgen'd files might vary along headers' structure.
    It made hard to track and update *really optimal* dependencies.

Each dependency to intrinsics_gen and ClangSACheckers is left as DEPENDS.

llvm-svn: 201842

llvm-svn: 201841

llvm-svn: 201840

class.  If we try to unwind a stack frame to find a caller stack
frame, and we fail to get a valid-looking frame, AND if the UnwindPlan
we used is an assembly-inspection based UnwindPlan, then we should 
throw away the assembly-inspection UnwindPlan and try unwinding with 
the architectural default UnwindPlan.  

This code path won't be taken if eh_frame unwind instructions are available -
lldb will always prefer those once it's off the zeroth frame.

The problem I'm trying to fix here is the class of unwind failures that
happen when we have hand-written assembly on the stack, with no eh_frame,
and lldb's assembly parser fails to understand the assembly.  People usually
write their hand-written assembly to follow the frame-pointer-preserving
conventions of the platform so the architectural default UnwindPlan will 
often work.  We won't have the spill location for most of the non-volatile
registers if we fall back to this, but it's better than stopping the unwind
prematurely.

This is a bit of a tricky change that I believe is correct, but if we get
unwinds that go of into the weeds / unwind bogus frames at the end of the
stack, I'll need to revisit it.

<rdar://problem/16099440> 

llvm-svn: 201839

Disable it on non-X86-64 platforms and add a comment.

llvm-svn: 201838

llvm-svn: 201837