| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Sanitizer common, enable OpenBSD platform.
- Enable common interceptors as possible and create few distinct ones.
- Create necessary sanitizer_struct types.
Patch by: David CARLIER
Reviewers: krytarowski, vitalybuka, visa, kettenis
Reviewed By: vitalybuka
Subscribers: emaste, srhines, kubamracek, mgorny, fedor.sergeev, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D43909
llvm-svn: 326650
|
| |
|
|
|
|
| |
Noted by <eugenis> in D43613
llvm-svn: 326649
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Basic support of Sanitiser to follow-up ubsan support in compiler-rt.
Needs to use lld instead of base ld to be fully workable.
Patch by: David CARLIER
Reviewers: krytarowski, vitalybuka, kettenis
Reviewed By: vitalybuka
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43961
llvm-svn: 326648
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Moving from ptr to u64 for GetTid posix implementation.
[FreeBSD] Moving from pthread_self to thr_self more appropriate to get thread ID.
Patch by: David CARLIER
Reviewers: krytarowski, vitalybuka
Reviewed By: vitalybuka
Subscribers: kubamracek, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D43998
llvm-svn: 326647
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
On OpenBSD no multi arch support
Enabling only UBsan and disabling Asan.
Patch by: David CARLIER
Reviewers: krytarowski, vitalybuka
Reviewed By: vitalybuka
Subscribers: srhines, mgorny, fedor.sergeev, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D44017
llvm-svn: 326646
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- Like other *BSD, conditioning certain flags to pass
- To prepare future OpenBSD sanitisers.
Patch by: David CARLIER
Reviewers: dlj, krytarowski, vitalybuka
Reviewed By: vitalybuka
Subscribers: krytarowski, cfe-commits
Differential Revision: https://reviews.llvm.org/D43818
llvm-svn: 326645
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Enabling the memory sanitizer support for FreeBSD, most of unit tests are compatible.
- Adding fstat and stressor_r interceptors.
- Updating the struct link_map access since most likely the struct Obj_Entry had been updated since.
- Disabling few unit tests until further work is needed (or we can assume it can work in real world code).
Patch by: David CARLIER
Reviewers: vitalybuka, krytarowski
Reviewed By: vitalybuka
Subscribers: eugenis, dim, srhines, emaste, kubamracek, mgorny, fedor.sergeev, hintonda, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D43080
llvm-svn: 326644
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
During codegen, Polly attempts to clear all loops from ScalarEvolution
and LoopInfo, and it does so one block at a time. This causes undefined
behaviour, since this way a loop header might be removed from a loop
before the entire loop is erased, causing ScalarEvolution to run into an
error.
Instead, just delete the entire loop atomically. This fixes currently
failing testcases.
llvm-svn: 326643
|
| |
|
|
| |
llvm-svn: 326642
|
| |
|
|
|
|
|
| |
Since r321982 we don't set VersionId in scanShlibUndefined, which
makes InVersionScript redundant.
llvm-svn: 326641
|
| |
|
|
| |
llvm-svn: 326640
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently only calls to mcount were suppressed with
no_instrument_function attribute.
Linux kernel requires that calls to fentry should also not be
generated.
This is an extended fix for PR PR33515.
Reviewers: hfinkel, rengolin, srhines, rnk, rsmith, rjmccall, hans
Reviewed By: rjmccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43995
llvm-svn: 326639
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This caused some links to fail with ThinLTO due to missing symbols as
well as causing some binaries to have failures at runtime. We're working
with the author to get a test case, but want to get the tree green
again.
Further, it appears to introduce a data race. While the test usage of
threads was disabled in r325361 & r325362, that isn't an acceptable fix.
I've reverted both of these as well. This code needs to be thread safe.
Test cases for this are already on the original commit thread.
llvm-svn: 326638
|
| |
|
|
|
|
|
|
|
|
|
|
| |
use a SCALAR_TO_VECTOR rather than a single element BUILD_VECTOR to convert back to a vector type.
X86 considers v1i1 a legal type under AVX512 and as such a truncate from a v1iX type to v1i1 can be turned into a scalar truncate plus a conversion to v1i1. We would much prefer a v1i1 SCALAR_TO_VECTOR over a one element BUILD_VECTOR.
During lowering we were detecting the v1i1 BUILD_VECTOR as a splat BUILD_VECTOR like we try to do for v2i1/v4i1/etc. In this case we create (select i1 splat_elt, v1i1 all-ones, v1i1 all-zeroes). That goes through some more legalization and we end up with a CMOV choosing between 0 and 1 in scalar and a scalar_to_vector.
Arguably we could detect the v1i1 BUILD_VECTOR and do this better in X86 target code. But just using a SCALAR_TO_VECTOR in legalization is much easier.
llvm-svn: 326637
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D43989
llvm-svn: 326636
|
| |
|
|
|
|
| |
use_empty() runs in O(1), whereas getNumUses() runs in O(# uses).
llvm-svn: 326635
|
| |
|
|
|
|
|
| |
It isn't actually necessary for what we are testing here and should
fix the test on the Linux bots.
llvm-svn: 326634
|
| |
|
|
|
|
| |
warnings; other minor fixes (NFC).
llvm-svn: 326633
|
| |
|
|
|
|
|
| |
Put the simplest non-FMF folds first, so it's easier to
see what's left to fix/group/add with the FMF folds.
llvm-svn: 326632
|
| |
|
|
|
|
|
|
|
|
|
| |
The fast/linear DAG scheduler doesn't lower DBG_VALUEs except for
function entry nodes.
Patch by Joshua Cranmer!
Differential Revision: https://reviews.llvm.org/D43028
llvm-svn: 326631
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The symbolizer was checking for .debug as a subdirectory of the
binary file itself, not of the directory containing the binary. This led to
a failure to find split debug info when it was contained in a .debug directory.
Reviewers: rnk, glider, zturner
Subscribers: llvm-commits, aprantl
Differential Revision: https://reviews.llvm.org/D44025
llvm-svn: 326630
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In stage2 -O3 builds of llc, this results in small but measurable
increases in the number of variables with locations, and in the number
of unique source variables overall.
(According to llvm-dwarfdump --statistics, there are 123 additional
variables with locations, which is just a 0.006% improvement).
The size of the .debug_loc section of the llc dsym increases by 0.004%.
llvm-svn: 326629
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out that setting the clang module cache after LLDB has a
Target can be too late. In particular, the Swift language plugin needs
to know the setting without having access to a Target. This patch
moves the setting into the *LLDB* module cache, where it is a global
setting that is available before any Target is created and more
importantly, is shared between all Targets.
rdar://problem/37944432
Differential Revision: https://reviews.llvm.org/D43984
llvm-svn: 326628
|
| |
|
|
| |
llvm-svn: 326627
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch implements relaxation for RISCV in the MC layer.
The following relaxations are currently handled:
1) Relax C_BEQZ to BEQ and C_BNEZ to BNEZ in RISCV.
2) Relax and C_J $imm to JAL x0, $imm and CJAL to JAL ra, $imm.
Reviewers: asb, llvm-commits, efriedma
Reviewed By: asb
Subscribers: shiva0217
Differential Revision: https://reviews.llvm.org/D43055
llvm-svn: 326626
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D43644
llvm-svn: 326625
|
| |
|
|
| |
llvm-svn: 326624
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I discovered that '-i' is a command line option for the driver,
however it actually does not do anything and is not supported by any
other compiler. In fact, it is completely undocumented for Clang.
I found a couple of instances of people confusing it with one of
the variety of other command line options that control the driver.
Because of this, we should delete this option so that it is clear
that it isn't valid.
HOWEVER, I found that GCC DOES support -imultilib, which the -i
was hiding our lack of support for. We currently only use imultilib
for the purpose of forwarding to gfortran (in a specific test written
by chandlerc for this purpose).
imultilib is a rarely used (if ever?) feature that I could find no
references to on the internet, and in fact, my company's massive test
suite has zero references to it ever being used.
SO, this patch removes the -i option so that we will now give an error
on its usage (so that it won't be confused with -I), and replaces it with
-imultilib, which is now specified as a gfortran_group option.
Differential Revision: https://reviews.llvm.org/D44032
llvm-svn: 326623
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We don't have special checks for BI_va_start in
Sema::CheckBuiltinFunctionCall, so setting the 't' flag for va_start in
Builtins.def disables semantic checking for it. That's not desired, and
IRGen crashes when it tries to generate a call to va_start that doesn't
have at least one argument.
Follow-up to r322573
Fixes PR36565
llvm-svn: 326622
|
| |
|
|
|
|
|
|
|
|
| |
In stage2 -O3 builds of llc, this results in a 0.3% increase in the
number of variables with locations, and a 0.2% increase in the number of
unique source variables overall.
The size of the .debug_loc section of the llc dsym increases by 0.5%.
llvm-svn: 326621
|
| |
|
|
| |
llvm-svn: 326620
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
initialization in if-expression
```
if (NSNumber* x = ...)
```
is a reasonable pattern in objc++, we should not warn on it.
rdar://35152234
Differential Revision: https://reviews.llvm.org/D44044
llvm-svn: 326619
|
| |
|
|
|
|
|
|
|
|
|
| |
This cast was causing invalid signatures to be written
for libcall functions.
Add an MC test which includes a call to builtin memcpy.
Differential Revision: https://reviews.llvm.org/D44037
llvm-svn: 326618
|
| |
|
|
|
|
|
|
|
|
| |
creating overly small ConstantFPs that we'll just need to extend again.
Instead of returning the smaller FP constant we now return the minimal Type the constant can fit into. We also return the Type of the input to any fp extends. The legality checks are then done on just the size of these Types. If we find something profitable we then emit FPTruncs in front of the smaller binop and assume those FPTruncs will be constant folded or combined with any ConstantFPs or fpextends.
Differential Revision: https://reviews.llvm.org/D44038
llvm-svn: 326617
|
| |
|
|
|
|
| |
I forgot to check in the updated test cases after the r326613 commit.
llvm-svn: 326616
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D43849
llvm-svn: 326615
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Original change was D43991 (rL326541) and was reverted by rL326571 and
rL326572. This adds also the necessary MCCodeEmitter patch.
Reviewers: sbc100
Subscribers: jfb, dschuff, sbc100, jgravelle-google, sunfish, llvm-commits, ncw
Differential Revision: https://reviews.llvm.org/D44034
llvm-svn: 326614
|
| |
|
|
|
|
|
|
| |
The byte-swapping loads and stores do not actually perform multiple
accesses to their memory operand, so they are OK to use with volatile
memory operands as well. Remove overly cautious check.
llvm-svn: 326613
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This adds back-end support for the anyregcc calling convention
for use with patchpoints.
Since all registers are considered call-saved with anyregcc
(except for 0 and 1 which may still be clobbered by PLT stubs
and the like), this required adding support for saving and
restoring vector registers in prologue/epilogue code for the
first time. This is not used by any other calling convention.
llvm-svn: 326612
|
| |
|
|
|
|
|
| |
This adds back-end support for the @llvm.experimental.stackmap and
@llvm.experimental.patchpoint intrinsics.
llvm-svn: 326611
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On SystemZ we need to provide a register save area of 160 bytes to
any called function. This size needs to be added when allocating
stack in the function prologue. However, it was not accounted for
as part of MachineFrameInfo::getStackSize(); instead the back-end
used a private routine getAllocatedStackSize().
This is OK for code-gen purposes, but it breaks other users of
the getStackSize() routine, in particular it breaks the recently-
added -stack-size-section feature.
Fix this by updating the main stack size tracked by common code
(in emitPrologue) instead of using the private routine.
No change in code generation intended.
llvm-svn: 326610
|
| |
|
|
|
|
|
|
| |
This adds support for specifying vector registers for use with inline
asm statements, either via the 'v' constraint or by explicit register
names (v0 ... v31).
llvm-svn: 326609
|
| |
|
|
|
|
|
|
|
|
| |
The code was checking that all of the instructions in the
sequence are 'fast', but that's not necessary. The final
multiply is all that we need to check (tests adjusted).
The fmul doesn't need to be fully 'fast' either, but that
can be another patch.
llvm-svn: 326608
|
| |
|
|
| |
llvm-svn: 326607
|
| |
|
|
|
|
|
|
| |
This narrow fold was added with no motivation or test cases
a bit over 5 years ago. Removing a constant operand is a
good canonicalization? We should handle Y*2.0 too then?
llvm-svn: 326606
|
| |
|
|
|
|
|
|
| |
check.
The test case previously triggered an assertion in the AST matchers because the QualType being matched is invalid. That is no longer the case after r326604.
llvm-svn: 326605
|
| |
|
|
|
|
| |
There's not a particularly good way to test this with the AST matchers unit tests because the only way to get an invalid type (that I can devise) involves creating parse errors, which the test harness always treats as a failure. Instead, a clang-tidy test case will be added in a follow-up commit based on the original bug report.
llvm-svn: 326604
|
| |
|
|
|
|
| |
Suggested at: https://reviews.llvm.org/D43248
llvm-svn: 326603
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch fixes a number of bugs related to parameter indexing in
attributes:
* Parameter indices in some attributes (argument_with_type_tag,
pointer_with_type_tag, nonnull, ownership_takes, ownership_holds,
and ownership_returns) are specified in source as one-origin
including any C++ implicit this parameter, were stored as
zero-origin excluding any this parameter, and were erroneously
printing (-ast-print) and confusingly dumping (-ast-dump) as the
stored values.
* For alloc_size, the C++ implicit this parameter was not subtracted
correctly in Sema, leading to assert failures or to silent failures
of __builtin_object_size to compute a value.
* For argument_with_type_tag, pointer_with_type_tag, and
ownership_returns, the C++ implicit this parameter was not added
back to parameter indices in some diagnostics.
This patch fixes the above bugs and aims to prevent similar bugs in
the future by introducing careful mechanisms for handling parameter
indices in attributes. ParamIdx stores a parameter index and is
designed to hide the stored encoding while providing accessors that
require each use (such as printing) to make explicit the encoding that
is needed. Attribute declarations declare parameter index arguments
as [Variadic]ParamIdxArgument, which are exposed as ParamIdx[*]. This
patch rewrites all attribute arguments that are processed by
checkFunctionOrMethodParameterIndex in SemaDeclAttr.cpp to be declared
as [Variadic]ParamIdxArgument. The only exception is xray_log_args's
argument, which is encoded as a count not an index.
Differential Revision: https://reviews.llvm.org/D43248
llvm-svn: 326602
|
| |
|
|
|
|
|
|
| |
Patch by Reshabh Sharma!
Differential Revision: https://reviews.llvm.org/D43939
llvm-svn: 326601
|