| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Use -fsanitize-recover instead of -mllvm -msan-keep-going.
Reviewers: eugenis
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D26352
llvm-svn: 286145
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
expansions by calling getSpellingLoc(). That's great in most cases, but for
macros defined in the '<built-in>' source file, the source file is invalid
and does not import correctly, causing an assertion failure (the assertion
is Invalid SLocOffset or bad function choice).
A more reliable way to avoid this is to use getFileLoc(), which does not
return built-in locations. This avoids the crash but still preserves valid
source locations.
I've added a testcase that covers the previously crashing scenario.
https://reviews.llvm.org/D26054
llvm-svn: 286144
|
| |
|
|
| |
llvm-svn: 286141
|
| |
|
|
| |
llvm-svn: 286140
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Similar to r283798, this prevents accidentally referring to temporary
storage that goes out of scope by the end of the statement:
someStringRef = getStringByValue();
someStringRef = (Twine("-") + otherString).str();
Note that once again the constructor still has this problem:
StringRef someStringRef = getStringByValue();
because once again we occasionally rely on this in calls:
takesStringRef(getStringByValue());
takesStringRef(Twine("-") + otherString);
Still, it's a step.
llvm-svn: 286139
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a new script in llvm/utils/git-svn/. When present in the $PATH,
it enables a `git llvm` command. It is providing at this
point only the ability to push from the git monorepo: `git llvm push`.
It is intended to evolves with more features, for instance I plan on
features like `git llvm show r284955` to help working with sequential
revision numbers.
The push feature is taken from Justin Lebar's script available here:
https://github.com/jlebar/llvm-repo-tools/
Differential Revision: https://reviews.llvm.org/D26334
llvm-svn: 286138
|
| |
|
|
| |
llvm-svn: 286137
|
| |
|
|
|
|
|
|
|
|
| |
accesses, compiler-rt part
Although rare, atomic accesses to floating-point types seem to be valid, i.e. `%a = load atomic float ...`. The TSan instrumentation pass however tries to emit inttoptr, which is incorrect, we should use a bitcast here. Anyway, IRBuilder already has a convenient helper function for this.
Differential Revision: https://reviews.llvm.org/D26266
llvm-svn: 286136
|
| |
|
|
|
|
|
|
|
|
| |
accesses, LLVM part
Although rare, atomic accesses to floating-point types seem to be valid, i.e. `%a = load atomic float ...`. The TSan instrumentation pass however tries to emit inttoptr, which is incorrect, we should use a bitcast here. Anyway, IRBuilder already has a convenient helper function for this.
Differential Revision: https://reviews.llvm.org/D26266
llvm-svn: 286135
|
| |
|
|
|
|
|
| |
The comment explaining why this was necessary is incorrect
in its description of v_cmp's behavior for inactive workitems.
llvm-svn: 286134
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If the branch was on a read-undef of vcc, passes that used
analyzeBranch to invert the branch condition wouldn't preserve
the undef flag resulting in a verifier error.
Fixes verifier failures in a future commit.
Also fix verifier error when inserting copy for vccz
corruption bug.
llvm-svn: 286133
|
| |
|
|
| |
llvm-svn: 286132
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The C++ side of the Go bindings were updated in r286085, r286086, and r286087,
but those did not remove this type.
Reviewers: djasper
Subscribers: axw
Differential Revision: https://reviews.llvm.org/D26337
llvm-svn: 286131
|
| |
|
|
| |
llvm-svn: 286130
|
| |
|
|
|
|
|
|
|
|
|
|
| |
constructs.
For __real/__imag unary expressions clang emits lvalue with the
associated type from the original complex expression, but not the
underlying builtin integer or float type. This causes crash in codegen
for atomic constructs, if __real/__imag expression are used in atomic
constructs.
llvm-svn: 286129
|
| |
|
|
|
|
|
|
| |
- Remove unused imports.
- Initialize the variable 'name' before its (static) uses, and rename it to a
more descriptive name.
llvm-svn: 286128
|
| |
|
|
|
|
|
|
|
| |
Argument evaluation order is one of the edge cases where Clang differs
from GCC, yielding different IR depending on which compiler LLVM was
built with. Make the order deterministic and tune the test to actually
verify the order instead of trying to hide it.
llvm-svn: 286126
|
| |
|
|
|
|
|
| |
Fixes crashes in tests such as test/CodeGen/X86/masked_gather_scatter.ll which
contains a RUN: with no pipe chain.
llvm-svn: 286125
|
| |
|
|
|
|
| |
This reverts commit r286123, accidentally commited while testing itself...
llvm-svn: 286124
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Some changes are made to cmake, especially the addition of a new
LLVM_ENABLE_PROJECTS option that makes the build system aware of
the monorepo directory structure.
Also a new script is added in llvm/utils/git-svn/. When present in
the $PATH, it enables a `git llvm` command. It is providing at this
point only the ability to push from the git monorepo: `git llvm push`.
It is intended to evolves with more features, for instance I plan on
features like `git llvm show r284955` to help working with sequential
revision numbers.
The push feature is taken from Justin Lebar's script available here:
https://github.com/jlebar/llvm-repo-tools/
Reviewers: jlebar
Subscribers: mgorny, modocache, llvm-commits
Differential Revision: https://reviews.llvm.org/D26334
llvm-svn: 286123
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The fixed code is basically identical to the same loop below, which
might indicate an opportunity for refactoring. I just wanted to fix
the use-of-temporary issue.
Caught by adding a similar check to StringRef as r283798 did for
ArrayRef. I'll be upstreaming that soon.
Reviewed by Vedant Kumar as https://reviews.llvm.org/D26317.
llvm-svn: 286122
|
| |
|
|
| |
llvm-svn: 286121
|
| |
|
|
| |
llvm-svn: 286120
|
| |
|
|
|
|
|
|
| |
gets to ISel.
Differential Revision: https://reviews.llvm.org/D26292
llvm-svn: 286119
|
| |
|
|
|
|
| |
Separate the subregister splitting logic to re-use later.
llvm-svn: 286118
|
| |
|
|
| |
llvm-svn: 286117
|
| |
|
|
| |
llvm-svn: 286116
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch allows ThreadSanitizer (Tsan) to verify OpenMP programs.
It means that no false positive will be reported by Tsan when
verifying an OpenMP programs.
This patch introduces annotations within the OpenMP runtime module to
provide information about thread synchronization to the Tsan runtime.
In order to enable the Tsan support when building the runtime, you must
enable the TSAN_SUPPORT option with the following environment variable:
-DLIBOMP_TSAN_SUPPORT=TRUE
The annotations will be enabled in the main shared library
(same mechanism of OMPT).
Patch by Simone Atzeni and Joachim Protze!
Differential Revision: https://reviews.llvm.org/D13072
llvm-svn: 286115
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D26302
llvm-svn: 286114
|
| |
|
|
|
|
|
|
| |
This was reverted at r285866 because there was a crash handling a scalar
select of vectors. I added a check for that pattern and a test case based
on the example provided in the post-commit thread for r285732.
llvm-svn: 286113
|
| |
|
|
|
|
|
|
|
| |
* Use a generic vector unit to model the issue unit more accurately.
* Update some vector instructions that actually use the vector unit for more
than one cycle.
Review: Ulrich Weigand
llvm-svn: 286112
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
asm register selection on AArch64.
Without this patch, register allocation for the example below fails.
define half @test(half %a1, half %a2) #0 {
entry:
%0 = tail call half asm "sqrshl ${0:h}, ${1:h}, ${2:h}", "=w,w,w" (half %a1, half %a2) #1
ret half %0
}
Patch by Florian Hahn.
Differential Revision: https://reviews.llvm.org/D25080
llvm-svn: 286111
|
| |
|
|
|
|
|
|
| |
This feature has been disabled for some time now, so remove cruft.
Differential Revision: https://reviews.llvm.org/D26248
llvm-svn: 286110
|
| |
|
|
|
|
|
|
| |
IssueWidth updated to reflect the capacity of the issue unit correctly.
Correct number of FX and LS units modelled (2, was 1).
Review: Ulrich Weigand
llvm-svn: 286109
|
| |
|
|
|
|
|
|
| |
actually affect memory.
Differential Revision: https://reviews.llvm.org/D26252
llvm-svn: 286108
|
| |
|
|
|
|
|
|
|
|
| |
When the base register (register pointing to the jump table) is the PC, we expect the jump table to directly follow the jump sequence with no intervening padding.
If there is intervening padding, the calculated offsets will not be correct. One solution would be to account for any padding in the emitted LDRB instruction, but at the moment we don't support emitting MCExprs for the load offset.
In the meantime, it's correct and only a slight amount worse to just move the padding up, from just before the jump table to just before the jump instruction sequence. We can do that by emitting code alignment before the jump sequence, as we know the number of instructions in the sequence is always 4.
llvm-svn: 286107
|
| |
|
|
| |
llvm-svn: 286106
|
| |
|
|
| |
llvm-svn: 286105
|
| |
|
|
|
|
| |
cpu/triple duplication
llvm-svn: 286104
|
| |
|
|
|
|
| |
After some changes in codegen capturing of VLA variables in OpenMP regions was broken, causing compiler crash. Patch fixes this issue.
llvm-svn: 286103
|
| |
|
|
|
|
|
| |
This reverts commit r286098 because the modified test breaks on many of the
buildbots.
llvm-svn: 286102
|
| |
|
|
|
|
|
|
|
| |
This renames the functionalities/postmortem/linux-core to elf-core and puts the
"linux" part into the individual names of the core files. Since the tests for
linux and freebsd core files are going to be very similar, having them close
together means they can reuse most of the plumbing.
llvm-svn: 286101
|
| |
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D26281
llvm-svn: 286100
|
| |
|
|
|
|
|
|
|
|
| |
In these tests there are some paths that explicitly throw, so use
the TEST_THROW macro that was proposed for this and then skip the tests
that may enter the throwing path.
Differential Revision: https://reviews.llvm.org/D26142
llvm-svn: 286099
|
| |
|
|
|
|
|
| |
After some changes in codegen capturing of VLA variables in OpenMP
regions was broken, causing compiler crash. Patch fixes this issue.
llvm-svn: 286098
|
| |
|
|
|
|
| |
embedded rounding control arguments.
llvm-svn: 286097
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The current version does not deduplicate equivalent file paths correctly.
For example, a relative path and an absolute path are considered inequivalent.
Comparing FileEnry addresses these issues.
Reviewers: djasper
Subscribers: alexshap, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D26288
llvm-svn: 286096
|
| |
|
|
| |
llvm-svn: 286095
|
| |
|
|
|
|
|
|
|
|
| |
Summary: Update the docs to match the changes in http://reviews.llvm.org/D7132
Reviewers: beanz, llvm-commits, modocache
Differential Revision: https://reviews.llvm.org/D26296
llvm-svn: 286094
|
| |
|
|
|
|
|
|
|
| |
We shouldn't access past the end of an array, even if we think that the
layout of the struct containing the array is always what we expect. The
compiler is free to optimize away the stores as undefined behavior, and
in fact, GCC 6.2.1 claims it will do exactly this.
llvm-svn: 286093
|