| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
| |
It's useful to be able to disable visibility annotations entirely; for
example, if we're building libc++abi static to include in another library,
and we don't want any libc++abi functions getting exported out of that
library. This is a generalization of _LIBCXXABI_DISABLE_DLL_IMPORT_EXPORT.
Differential Revision: https://reviews.llvm.org/D26950
llvm-svn: 288692
|
| |
|
|
|
|
| |
LLVM build trees export the gtest library through a special export set. If you're building against a build tree you shouldn't need to re-add gtest, but if you're building against an installed LLVM you do.
llvm-svn: 288691
|
| |
|
|
|
|
|
|
|
|
|
| |
It's useful to be able to disable visibility annotations entirely; for
example, if we're building libc++ static to include in another library,
and we don't want any libc++ functions getting exported out of that
library. This is a generalization of _LIBCPP_DISABLE_DLL_IMPORT_EXPORT.
Differential Revision: https://reviews.llvm.org/D26934
llvm-svn: 288690
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Similar to r288685.
getExceptionSpec returned structure with pointers to temporarily object created
by computeImplicitExceptionSpec.
Reviewers: rsmith
Subscribers: aizatsky, cfe-commits
Differential Revision: https://reviews.llvm.org/D27422
llvm-svn: 288689
|
| |
|
|
|
|
|
| |
Thanks to David Binderman <dcb314@hotmail.com> for bringing it to my
attention.
llvm-svn: 288688
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This diff
1. Adds a comment to ObjectFileELF.cpp about the current
approach to determining the OS.
2. Replaces the check in SymbolFileDWARF.cpp with a more robust one.
Test plan:
Built (on Linux) a test binary linked to a c++ shared library
which contains just an implementation of a function TestFunction,
the library (the binary itself) doesn't contain ELF notes
and EI_OSABI is set to System V.
Checked in lldb that now "p TestFunction()" works fine
(and doesn't work without this patch).
Differential revision: https://reviews.llvm.org/D27380
llvm-svn: 288687
|
| |
|
|
| |
llvm-svn: 288686
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
getExceptionSpec returns structure with pointers to temporarily object created
by computeImplicitExceptionSpec.
Reviewers: rsmith
Subscribers: aizatsky, cfe-commits
Differential Revision: https://reviews.llvm.org/D27420
llvm-svn: 288685
|
| |
|
|
|
|
|
|
| |
Also add a citation to GNU gold safe ICF paper.
Differential Revision: https://reviews.llvm.org/D27398
llvm-svn: 288684
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
so we can stop using DW_OP_bit_piece with the wrong semantics.
The entire back story can be found here:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20161114/405934.html
The gist is that in LLVM we've been misinterpreting DW_OP_bit_piece's
offset field to mean the offset into the source variable rather than
the offset into the location at the top the DWARF expression stack. In
order to be able to fix this in a subsequent patch, this patch
introduces a dedicated DW_OP_LLVM_fragment operation with the
semantics that we used to apply to DW_OP_bit_piece, which is what we
actually need while inside of LLVM. This patch is complete with a
bitcode upgrade for expressions using the old format. It does not yet
fix the DWARF backend to use DW_OP_bit_piece correctly.
Implementation note: We discussed several options for implementing
this, including reserving a dedicated field in DIExpression for the
fragment size and offset, but using an custom operator at the end of
the expression works just fine and is more efficient because we then
only pay for it when we need it.
Differential Revision: https://reviews.llvm.org/D27361
rdar://problem/29335809
llvm-svn: 288683
|
| |
|
|
|
|
|
|
|
|
|
| |
On MSVC, if an implicit instantiation already exists and an explicit
instantiation definition with a DLL attribute is created, the DLL
attribute still takes effect. Make clang match this behavior for
exporting.
Differential Revision: https://reviews.llvm.org/D26657
llvm-svn: 288682
|
| |
|
|
|
|
|
|
| |
Since we’re adding an entry into COMPILER_RT_SUPPORTED_ARCH for all architectures of all Darwin platforms, COMPILER_RT_SUPPORTED_ARCH often ends up having duplicate items. Let’s remove them.
Differential Revision: https://reviews.llvm.org/D25996
llvm-svn: 288681
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Linux (and probably on other Unix-like systems), unlink(2) is
noticeably slow. It takes 250 milliseconds to remove a 1 GB file
on ext4 filesystem on my machine, whether the file is on SSD or
on a spinning disk.
To create a new result file, we remove existing file first. So, if
you repeatedly link a 1 GB program in a regular compile-link-debug
cycle, every cycle wastes 250 milliseconds only to remove a file.
Since LLD can link a 1 GB in about 5 seconds, that waste actually
matters.
This patch defines `unlinkAsync` function. The function spawns a
background thread to call unlink. The calling thread returns
almost immediately.
Differential Revision: https://reviews.llvm.org/D27295
llvm-svn: 288680
|
| |
|
|
|
|
| |
This fix, while a bit complicated, preserves the reusability while fixing the issues reported on llvm-commits with visual studio generators.
llvm-svn: 288679
|
| |
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D27335
llvm-svn: 288678
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On a method call, the ObjCGenerics checker uses the type tracked by
DynamicTypePropagation for the receiver to to infer substituted parmeter types
for the called methods and warns when the argument type does not match the
parameter.
Unfortunately, using the tracked type can result in false positives when the
receiver has a non-invariant type parameter and has been intentionally upcast.
For example, becaue NSArray's type parameter is covaraint, the following code
is perfectly safe:
NSArray<NSString *> *allStrings = ...
NSDate *date = ...;
NSArray<NSObject *> *allObjects = allStrings;
NSArray<NSObject *> *moreObjects = [allObjects arrayByAddingObject:date];
but the checker currently warns that the date parameter is not an NSString *.
To avoid this kind of false positive, the checker will now only warn when
the class defining the called method has only invariant type parameters.
rdar://problem/28803951
llvm-svn: 288677
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We treat bitwise 'not' as a special operation and try not to reduce its all-ones mask.
Presumably, this is because a 'not' may be cheaper than a generic 'xor' or it may get
folded into another logic op if the target has those. However, if we can remove a logic
instruction by changing the xor's constant mask value, that should always be a win.
Note that the IR version of SimplifyDemandedBits() does not treat 'not' as a special-case
currently (although that's marked with a FIXME). So if you run this IR through -instcombine,
you should get the same end result. I'm hoping to add a different backend transform that
will expose this problem though, so I need to solve this first.
Differential Revision: https://reviews.llvm.org/D27356
llvm-svn: 288676
|
| |
|
|
|
|
|
|
|
|
|
| |
I noticed this gap in the scalar FP-logic matching with:
D26712
and:
rL287171
Differential Revision: https://reviews.llvm.org/D27385
llvm-svn: 288675
|
| |
|
|
|
|
|
| |
This file is not in the include path when building with a non-standalone
toolchain. In does not seem to be necessary anyway.
llvm-svn: 288674
|
| |
|
|
| |
llvm-svn: 288673
|
| |
|
|
|
|
|
|
|
|
|
|
| |
TSan runtime shouldn't contain memset, so internal_memset is used
instead and syntax that emits memset is avoided.
This doesn't fail in-tree due to TSan being build with -03, but it fails
when TSan is built with -O0, and is (I think) a true positive.
Patch by Sam McCall, review: https://reviews.llvm.org/D27407
llvm-svn: 288672
|
| |
|
|
| |
llvm-svn: 288671
|
| |
|
|
|
|
|
|
|
|
|
| |
The relocation R_AARCH64_LDST16_ABS_LO12_NC should set a ld/st
immediate value to bits [11:1] not [11:2]. This patches fixes it
and adds a testcase for regression.
With this fix all the faulty tests on test-suite (clavm, lencod,
and trimaran) pass.
llvm-svn: 288670
|
| |
|
|
|
|
|
| |
This patch uses the updateAArch64Add on relocation apply and remove
the comment.
llvm-svn: 288669
|
| |
|
|
|
|
|
| |
This patch avoid getAArch64Page code duplication by removing the
implementation at InputSection.
llvm-svn: 288668
|
| |
|
|
|
|
|
|
| |
parsing tests.
NFC intended.
llvm-svn: 288667
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Doing so changes the evaluation order for relocation composition.
Patch By: Daniel Sanders
Reviewers: vkalintiris, atanasyan
Differential Revision: https://reviews.llvm.org/D26401
llvm-svn: 288666
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
CXXDeleteExpr::getDestroyedType() can return a null QualType if the destroyed
type is a dependent type. This patch protects against this.
Reviewers: klimek
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D27350
llvm-svn: 288665
|
| |
|
|
| |
llvm-svn: 288664
|
| |
|
|
| |
llvm-svn: 288663
|
| |
|
|
| |
llvm-svn: 288662
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rationale:
scripts/Python/modules: android is excluded at a higher level, so no point in
checking here
tools/lldb-mi: lldb-mi builds fine (with some cosmetic tweaks) on android, and
there is no reason it shouldn't.
tools/lldb-server: LLDB_DISABLE_LIBEDIT/CURSES already take the platform into
account, so there is no point in checking again.
I am reasonably confident this should not break the build on any platform, but
I'll keep an eye out on the bots.
llvm-svn: 288661
|
| |
|
|
|
|
|
|
|
|
| |
Under libcpp-no-exceptions, noexcept is trivially true. Some tests expect in
the usual setting to return false, so adjust them to expect true under
libcpp-no-exceptions.
Differential Revision: https://reviews.llvm.org/D27310
llvm-svn: 288660
|
| |
|
|
| |
llvm-svn: 288659
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This function seems target-independent so far: all the target-specific behaviour
is isolated in the CCAssignFn and the ValueHandler (which we're also extracting
into the generic CallLowering).
The intention is to use this in the ARM backend.
Differential Revision: https://reviews.llvm.org/D27045
llvm-svn: 288658
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: s_buffer_store_dword instructions sdata operand was called sdst in encoding. This caused disassembler to fail.
Reviewers: tstellarAMD, vpykhtin, artem.tamazov
Subscribers: arsenm, nhaehnle, rampitec
Differential Revision: https://reviews.llvm.org/D27100
llvm-svn: 288657
|
| |
|
|
|
|
|
|
|
| |
Include component in install rules for Sphinx targets. Based on
a similar suggestion for other doc targets in D24935.
Differential Revision: https://reviews.llvm.org/D24982
llvm-svn: 288656
|
| |
|
|
|
|
|
|
|
| |
A debug build of AsmMatcherEmitter would use a quadratic algorithm to
check whether std::stable_sort() actually sorted. Let's hope the authors
of our C++ standard library did that testing for us. Removing the check
gives a 3x speedup in the X86 case.
llvm-svn: 288655
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
latter case, a temporary array object is materialized, and can be
lifetime-extended by binding a reference to the member access. Likewise, in an
array-to-pointer decay, an rvalue array is materialized before being converted
into a pointer.
This caused IR generation to stop treating file-scope array compound literals
as having static storage duration in some cases in C++; that has been rectified
by modeling such a compound literal as an lvalue. This also improves clang's
compatibility with GCC for those cases.
llvm-svn: 288654
|
| |
|
|
| |
llvm-svn: 288653
|
| |
|
|
|
|
|
|
| |
This may seem unusual, but makes most debug tblgen builds ~10% faster.
Usually we wouldn't care about speed that much in debug builds, but for
tblgen that also translates into build time.
llvm-svn: 288652
|
| |
|
|
| |
llvm-svn: 288651
|
| |
|
|
| |
llvm-svn: 288650
|
| |
|
|
| |
llvm-svn: 288649
|
| |
|
|
| |
llvm-svn: 288648
|
| |
|
|
| |
llvm-svn: 288647
|
| |
|
|
|
|
| |
comparison. MVT's operator== already takes care of this. NFCI
llvm-svn: 288646
|
| |
|
|
| |
llvm-svn: 288645
|
| |
|
|
| |
llvm-svn: 288644
|
| |
|
|
| |
llvm-svn: 288643
|