No any changes, will follow up with D28807 commit containing APLi change for clang
to fix build issues happened.
Original commit message:
[Support/Compression] - Change zlib API to return Error instead of custom status.
Previously API returned custom enum values.
Patch changes it to return Error with string description.
That should help users to report errors in universal way.
Differential revision: https://reviews.llvm.org/D28684
llvm-svn: 292226
Summary:
Tests under tools/llvm-objdump should not use inputs from Object. Copied the
required inputs and aligned the new tests to be more consistent with the existing
tests in this respect.
Reviewers: ioeric
Reviewed By: ioeric
Subscribers: davide, djasper, cfe-commits
Differential Revision: https://reviews.llvm.org/D28799
llvm-svn: 292222
Inputs shown in that testcase previously created
a huge temporarily file under 32 bits.
It was fixed by D28107. During review was suggested to
add a testcase even without CHECKs for documentation purposes.
Patch do that.
llvm-svn: 292220
Patch changes behavior to not try open the output
file if we already know about error.
That is not just cleaner, but also fixes nasty behavior of linker that
could create huge temporarily files under certain conditions.
Differential revision: https://reviews.llvm.org/D28107
llvm-svn: 292219
Previously API returned custom enum values.
Patch changes it to return Error with string description.
That should help users to report errors in universal way.
Differential revision: https://reviews.llvm.org/D28684
llvm-svn: 292214
Summary:
Instead of forbidding such access functions completely, we verify that their
base pointer has been hoisted and only assert in case the base pointer was
not hoisted.
I was trying for a little while to get a test case that ensures the assert is
correctly fired in case of invariant load hoisting being disabled, but I could
not find a good way to do so, as llvm-lit immediately aborts if a command
yields a non-zero return value. As we do not generally test our asserts,
not having a test case here seems OK.
This resolves http://llvm.org/PR31494
Suggested-by: Michael Kruse <llvm@meinersbur.de>
Reviewers: efriedma, jdoerfert, Meinersbur, gareevroman, sebpop, zinob, huihuiz, pollydev
Reviewed By: Meinersbur
Differential Revision: https://reviews.llvm.org/D28798
llvm-svn: 292213
Summary:
The NDK cmake toolchain file defines CMAKE_SYSTEM_NAME=Android, so switch the
build to use that. I have also updated the in-tree toolchain file to do that
(instead of defining __ANDROID_NDK__), so it can still be used to build.
After migrating the last bits of non-toolchainy bits out of the in-tree
toolchain, I intend to delete it.
Reviewers: tberghammer, danalbert
Subscribers: srhines, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D28775
llvm-svn: 292212
Summary:
Testing of XRay was occasionally disabled on 32-bit Arm targets (someone assumed that XRay was supported on 64-bit targets only). This patch should fix that problem. Also here the instruction&data cache incoherency problem is fixed, because it may be causing a test to fail.
This patch is one of a series: see also
- https://reviews.llvm.org/D28624
Reviewers: dberris, rengolin
Reviewed By: rengolin
Subscribers: llvm-commits, aemerson, rengolin, dberris, iid_iunknown
Differential Revision: https://reviews.llvm.org/D28623
llvm-svn: 292211
Summary:
Emission of XRay table was occasionally disabled for Arm32, but this bug was not then detected because earlier (also by mistake) testing of XRay was occasionally disabled on 32-bit Arm targets. This patch should fix that problem and detect such problems in the future.
This patch is one of a series, see also
- https://reviews.llvm.org/D28623
Reviewers: rengolin, dberris
Reviewed By: dberris
Subscribers: llvm-commits, aemerson, rengolin, dberris, iid_iunknown
Differential Revision: https://reviews.llvm.org/D28624
llvm-svn: 292210
Summary:
Also ignore helpers which are defined in macro. Currently clang-move doesn't
handle macro well enough, especiall for complex macros. This patch will ignore
declarations in macros to make the behavior of clang-move more correct.
Reviewers: ioeric
Reviewed By: ioeric
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28774
llvm-svn: 292207
Emit error when BPF backend sees a call to a global function or to an external symbol.
The kernel verifier only allows calls to predefined helpers from bpf.h
which are defined in 'enum bpf_func_id'. Such calls in assembler must
look like 'call [1-9]+' where number matches bpf_func_id.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
llvm-svn: 292204
This allows us to use bin/llvm-lit to run individual libc++ and
libc++abi tests without having to explicitly specify the site config
paths, similar to other projects.
Differential Revision: https://reviews.llvm.org/D28733
llvm-svn: 292203
Using the canonical type instead of the equivalent type can result in
insufficient template instantiations.
This fixes PR31656.
Differential Revision: https://reviews.llvm.org/D28788
llvm-svn: 292194
negotiateFunction.
These cases were accidentally left out of r292055, resulting in a less
descriptive ECError being returned on these paths.
llvm-svn: 292193
-mglobal-merge is translated to the appropriate backend option in
the driver. r277322 changed the AArch64 option name in the backend,
but the driver was never updated.
llvm-svn: 292192
In order to allow inlining of previously out-of-line functions without an ABI break
libc++ provides legacy definitions in the dylib that old programs can
continue to use. Unfortunatly Windows link.exe detects this hack and diagnoses the duplicate
definitions.
This patch disable the duplicate definitions on Windows by adding an ABI option
which disables all "legacy out-of-line symbols"
llvm-svn: 292190
SelectionDAGBuilder recognizes libfuncs using some homegrown
parameter type-checking.
Use TLI instead, removing another heap of redundant code.
This isn't strictly NFC, as the SDAG code was too lax.
Concretely, this means changes are required to two tests:
- calling a non-variadic function via a variadic prototype isn't OK;
it just happens to work on x86_64 (but not on, e.g., aarch64).
- mempcpy has a size_t parameter; the SDAG code accepts any integer
type, which meant using i32 on x86_64 worked.
I don't think it's worth supporting either of these (IMO) broken
testcases. Instead, fix them to be more correct.
llvm-svn: 292189
This is another step towards unifying all LibFunc prototype checks.
This work started in r267758 (D19469); add the remaining checks.
Also add a unittest that checks each libfunc declared with a known-valid
and known-invalid prototype. New libfuncs added in the future are
required to have prototype checking in place; the known-valid test will
fail otherwise.
Differential Revision: https://reviews.llvm.org/D28030
llvm-svn: 292188
Moves hot functions such as atomic add into the memory header file
so that they can be inlined, which brings performance benefits.
Patch by Kevin Hu, Aditya Kumar, Sebastian Pop
Differential Revision: https://reviews.llvm.org/D24991
llvm-svn: 292184
The rules around typechecking deduced template arguments during partial
ordering are not clear, and while the prior behavior does not seem to be
correct (it doesn't follow the general model of partial ordering where each
template parameter is replaced by a non-dependent but unique value), the new
behavior is also not clearly right and breaks some existing idioms.
The new behavior is retained for dealing with non-type template parameters
with 'auto' types, as without it even the most basic uses of that feature
don't work. We can revisit this once CWG has come to an agreement on how
partial ordering with 'auto' non-type template parameters is supposed to
work.
llvm-svn: 292183
George Rimar