We're going to extend DiagnoseUnimplementedProperties shortly to look for more cases
that aren't handled by default property synthesis.
llvm-svn: 201878
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
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
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_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
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
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
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
This replaces the old NoIntegratedAssembler with at TargetOption. This is
more flexible and will be used to forward clang's -no-integrated-as option.
llvm-svn: 201836
Virtual methods expect 'this' to point to the vfptr containing the
virtual method, and this extends to virtual member pointer thunks. The
relevant vfptr is always at offset zero on entry to the thunk, and no
this adjustment is needed.
Previously we would not include the vfptr adjustment in the member
pointer, and we'd look at the vfptr offset when loading from the vftable
in the thunk.
Fixes PR18917.
llvm-svn: 201835
Slight change to the way zero-sized sub-objects are tracked in the
presence of virtual bases.
In addition we correctly distinguish between dsize and nvsize.
addresses http://llvm.org/bugs/show_bug.cgi?id=18826
Unit tests are included.
llvm-svn: 201832
Ted Kremenek