| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
The D67717 excludes such locations for now.
llvm-svn: 373074
|
|
|
|
|
|
|
|
| |
ModuleList.cpp includes clang/Driver/Driver.h. Reflect that in the build
system. Not having this can cause build failures if ModuleList.cpp is
built before Driver.inc is generated.
llvm-svn: 373073
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Windows unwinding is weird. The unwind rules do not (always) describe
the precise layout of the stack, but rather expect the debugger to scan
the stack for something which looks like a plausible return address, and
the unwind based on that. The reason this works somewhat reliably is
because the the unwinder also has access to the frame sizes of the
functions on the stack. This allows it (in most cases) to skip function
pointers in local variables or function arguments, which could otherwise
be mistaken for return addresses.
Implementing this kind of unwind mechanism in lldb was a bit challenging
because we expect to be able to statically describe (in the UnwindPlan)
structure, the layout of the stack for any given instruction. Giving a
precise desription of this is not possible, because it requires
correlating information from two functions -- the pushed arguments to a
function are considered a part of the callers stack frame, and their
size needs to be considered when unwinding the caller, but they are only
present in the unwind entry of the callee. The callee may end up being
in a completely different module, or it may not even be possible to
determine it statically (indirect calls).
This patch implements this functionality by introducing a couple of new
APIs:
SymbolFile::GetParameterStackSize - return the amount of stack space
taken up by parameters of this function.
SymbolFile::GetOwnFrameSize - the size of this function's frame. This
excludes the parameters, but includes stuff like local variables and
spilled registers.
These functions are then used by the unwinder to compute the estimated
location of the return address. This address is not always exact,
because the stack may contain some additional values -- for instance, if
we're getting ready to call a function then the stack will also contain
partially set up arguments, but we will not know their size because we
haven't called the function yet. For this reason the unwinder will crawl
up the stack from the return address position, and look for something
that looks like a possible return address. Currently, we assume that
something is a valid return address if it ends up pointing to an
executable section.
All of this logic kicks in when the UnwindPlan sets the value of CFA as
"isHeuristicallyDetected", which is also the final new API here. Right
now, only SymbolFileBreakpad implements these APIs, but in the future
SymbolFilePDB will use them too.
Differential Revision: https://reviews.llvm.org/D66638
llvm-svn: 373072
|
|
|
|
|
|
|
| |
This check was failing since it was added in r372837. It should be
possible to re-enable it once D68010 lands.
llvm-svn: 373071
|
|
|
|
|
|
| |
This relands r373029, reverted in 373033, because r373028 relanded in r373066.
llvm-svn: 373070
|
|
|
|
|
|
|
|
|
| |
Previously, these were unseen because the wrapper script would swallow
them. This fixes the following types of warnings:
- methods being declared more than once
- swig complained about ignoring operator=, so I just removed it
llvm-svn: 373069
|
|
|
|
| |
llvm-svn: 373068
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: kadircet
Reviewed By: kadircet
Subscribers: MaskRay, jkorous, arphaman, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D68120
llvm-svn: 373067
|
|
|
|
|
|
|
| |
This way, all tests will benefit from it and will not have to worry
about setting up language options properly.
llvm-svn: 373066
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
non-global storage.
Summary:
Creates a new darwin ClangTidy module and adds the darwin-dispatch-once-nonstatic check that warns about dispatch_once_t variables not in static or global storage. This catches a missing static for local variables in e.g. singleton initialization behavior, and also warns on storing dispatch_once_t values in Objective-C instance variables. C/C++ struct/class instances may potentially live in static/global storage, and are ignored for this check.
The osx.API static analysis checker can find the non-static storage use of dispatch_once_t; I thought it useful to also catch this issue in clang-tidy when possible.
This is a re-land of https://reviews.llvm.org/D67567
Reviewers: thakis, gribozavr, stephanemoore
Subscribers: Eugene.Zelenko, mgorny, xazax.hun, jkorous, arphaman, kadircet, usaxena95
Tags: #clang-tools-extra, #clang, #llvm
Differential Revision: https://reviews.llvm.org/D68109
llvm-svn: 373065
|
|
|
|
|
|
| |
Use different data types for some simple loops.
llvm-svn: 373064
|
|
|
|
| |
llvm-svn: 373063
|
|
|
|
|
|
| |
D64572 / rL365818 changed the way that the file paths were collected, which meant we lost the file pattern expansion necessary when working with DOS command prompt
llvm-svn: 373062
|
|
|
|
|
|
|
| |
According to a comment by Pavel Labath:
https://reviews.llvm.org/D67589#inline-612375
llvm-svn: 373061
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-max-jump-table-targets"
This caused severe compile-time regressions, see PR43455.
> Modern processors predict the targets of an indirect branch regardless of
> the size of any jump table used to glean its target address. Moreover,
> branch predictors typically use resources limited by the number of actual
> targets that occur at run time.
>
> This patch changes the semantics of the option `-max-jump-table-size` to limit
> the number of different targets instead of the number of entries in a jump
> table. Thus, it is now renamed to `-max-jump-table-targets`.
>
> Before, when `-max-jump-table-size` was specified, it could happen that
> cluster jump tables could have targets used repeatedly, but each one was
> counted and typically resulted in tables with the same number of entries.
> With this patch, when specifying `-max-jump-table-targets`, tables may have
> different lengths, since the number of unique targets is counted towards the
> limit, but the number of unique targets in tables is the same, but for the
> last one containing the balance of targets.
>
> Differential revision: https://reviews.llvm.org/D60295
llvm-svn: 373060
|
|
|
|
|
|
|
| |
causing extra indentation
Reason: this breaks unit tests.
llvm-svn: 373059
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The const-correctness of match() was fixed in rL372764, which allows
such static Regex objects to be marked const.
Reviewers: thopre
Reviewed By: thopre
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68091
llvm-svn: 373058
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: kadircet
Reviewed By: kadircet
Subscribers: MaskRay, jkorous, arphaman, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D68118
llvm-svn: 373057
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
indentation
The following code
```
struct f {
template <class T>
void bar() && noexcept {}
};
```
will be formatted to the following with LLVM style, and
`AlwaysBreakTemplateDeclarations: Yes`
```
struct f {
template <class T>
void bar() && noexcept {}
};
```
The indentation of the `void bar()` line is wrong.
Patch by Andreas Wass (AndWass)!
Differential Revision: https://reviews.llvm.org/D68072
llvm-svn: 373056
|
|
|
|
| |
llvm-svn: 373055
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790
Reviewers: courbet
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67922
llvm-svn: 373054
|
|
|
|
| |
llvm-svn: 373053
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Happens only when the mve.fp subtarget feature is enabled:
$ llvm-mc -triple thumbv8.1m.main -mattr=+mve.fp,+8msecext -disassemble <<< "0x9f,0xec,0x08,0x0b"
.text
vldmia pc, {d0, d1, d2, d3}
$ llvm-mc -triple thumbv8.1m.main -mattr=+8msecext -disassemble <<< "0x9f,0xec,0x08,0x0b"
.text
vscclrm {d0, d1, d2, d3, vpr}
Assembling returns the correct encoding with or without mve.fp:
$ llvm-mc -triple thumbv8.1m.main -mattr=+mve.fp,+8msecext -show-encoding <<< "vscclrm {d0-d3, vpr}"
.text
vscclrm {d0, d1, d2, d3, vpr} @ encoding: [0x9f,0xec,0x08,0x0b]
$ llvm-mc -triple thumbv8.1m.main -mattr=+8msecext -show-encoding <<< "vscclrm {d0-d3, vpr}"
.text
vscclrm {d0, d1, d2, d3, vpr} @ encoding: [0x9f,0xec,0x08,0x0b]
The problem seems to be in the TableGen description of VSCCLRMD.
The least significant bit should be set to zero.
Differential Revision: https://reviews.llvm.org/D68025
llvm-svn: 373052
|
|
|
|
| |
llvm-svn: 373051
|
|
|
|
|
|
|
|
| |
A lot of commands are made up of CommandObjectMultiword with
subcommands. CommandObjectMultiword actually has some functionality
on its own that wasn't tested before.
llvm-svn: 373050
|
|
|
|
|
|
|
| |
This broke in r371027 due to a missing negation
(llvm::sys::fs::current_path returns false on success).
llvm-svn: 373049
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Right now latency generation can incorrectly select the scratch register
as a dependency-carrying register.
- Move the logic for preventing register selection from Uops
implementation to common SnippetGenerator class.
- Aliasing detection now takes a set of forbidden registers just like
random register assignment does.
Reviewers: gchatelet
Subscribers: tschuett, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68084
llvm-svn: 373048
|
|
|
|
|
|
| |
Reviewer: tstellar
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 373047
|
|
|
|
|
|
|
|
| |
Use native packages up to llvm-6.
Reviewer: tstellar
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 373046
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
hasDedicatedExits.
For the compile time problem described in https://reviews.llvm.org/D67359,
turns out the root cause is there are many duplicates in ExitBlocks so
the algorithm complexity of hasDedicatedExits gets very high. If we remove
the duplicates, the compile time issue is gone.
Thanks to Philip Reames for raising a good question and it leads me to
find the root cause.
Differential Revision: https://reviews.llvm.org/D68107
llvm-svn: 373045
|
|
|
|
|
|
|
|
|
|
|
| |
exits"
Get a better approach in https://reviews.llvm.org/D68107 to solve the problem.
Revert the initial patch and will commit the new one soon.
This reverts commit rL372990.
llvm-svn: 373044
|
|
|
|
| |
llvm-svn: 373043
|
|
|
|
|
|
|
|
|
| |
We need to discard all remaining cleanups if an earlier cleanup failed,
otherwise we may try to rerun the remaining cleanups later, potentially
after the scope containing the object is destroyed. (This can happen
when checking a potential constant expression.)
llvm-svn: 373042
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As specified at
https://github.com/WebAssembly/simd/blob/master/proposals/simd/SIMD.md#bitwise-and-not
Reviewers: aheejin
Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68113
llvm-svn: 373041
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As specified at
https://github.com/webassembly/simd/blob/master/proposals/simd/SIMD.md#load-and-extend.
These instructions are behind the unimplemented-simd128 target feature
for now because they have not been implemented in V8 yet.
Reviewers: aheejin
Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68058
llvm-svn: 373040
|
|
|
|
|
|
| |
It breaks the build on MSVC.
llvm-svn: 373039
|
|
|
|
| |
llvm-svn: 373038
|
|
|
|
| |
llvm-svn: 373037
|
|
|
|
|
|
| |
constant evaluation.
llvm-svn: 373036
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can't use short granules with stack instrumentation when targeting older
API levels because the rest of the system won't understand the short granule
tags stored in shadow memory.
Moreover, we need to be able to let old binaries (which won't understand
short granule tags) run on a new system that supports short granule
tags. Such binaries will call the __hwasan_tag_mismatch function when their
outlined checks fail. We can compensate for the binary's lack of support
for short granules by implementing the short granule part of the check in
the __hwasan_tag_mismatch function. Unfortunately we can't do anything about
inline checks, but I don't believe that we can generate these by default on
aarch64, nor did we do so when the ABI was fixed.
A new function, __hwasan_tag_mismatch_v2, is introduced that lets code
targeting the new runtime avoid redoing the short granule check. Because tag
mismatches are rare this isn't important from a performance perspective; the
main benefit is that it introduces a symbol dependency that prevents binaries
targeting the new runtime from running on older (i.e. incompatible) runtimes.
Differential Revision: https://reviews.llvm.org/D68059
llvm-svn: 373035
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D67569
llvm-svn: 373034
|
|
|
|
|
|
| |
This reverts commit r373029, which depends on r373028, which I reverted.
llvm-svn: 373033
|
|
|
|
|
|
|
|
| |
non-static, non-global storage"
This reverts commit r373028, because the new test fails on Linux.
llvm-svn: 373032
|
|
|
|
|
|
| |
patterns and add COPY_TO_REGCLASS to them.
llvm-svn: 373031
|
|
|
|
| |
llvm-svn: 373029
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
non-global storage
Summary:
Creates a new darwin ClangTidy module and adds the darwin-dispatch-once-nonstatic check that warns about dispatch_once_t variables not in static or global storage. This catches a missing static for local variables in e.g. singleton initialization behavior, and also warns on storing dispatch_once_t values in Objective-C instance variables. C/C++ struct/class instances may potentially live in static/global storage, and are ignored for this check.
The osx.API static analysis checker can find the non-static storage use of dispatch_once_t; I thought it useful to also catch this issue in clang-tidy when possible.
Contributed By: mwyman
Reviewers: benhamilton, hokein, stephanemoore, aaron.ballman, gribozavr
Reviewed By: stephanemoore, gribozavr
Subscribers: jkorous, arphaman, kadircet, usaxena95, NoQ, xazax.hun, lebedev.ri, mgorny, cfe-commits
Tags: #clang, #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D67567
llvm-svn: 373028
|
|
|
|
| |
llvm-svn: 373026
|
|
|
|
|
|
|
|
|
| |
We have isel patterns that can put an IMPLICIT_DEF on one of
the sources for these instructions. So we should make sure
we break any dependencies there. This should be done by
just using one of the other sources.
llvm-svn: 373025
|
|
|
|
|
|
|
|
|
|
| |
Reviewers:
arsenm
Differential Revision:
https://reviews.llvm.org/D58360
llvm-svn: 373024
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patches fixes the case when a user-defined mapper is attached to
the elements of an array, and to report error when a mapper is used for
types other than struct, class, and union.
Patch by Lingda Li <lildmh@gmail.com>
Differential Revision: https://reviews.llvm.org/D67978
llvm-svn: 373023
|