| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Backing out because SymbolFile/Breakpad/symtab.test is failing and it seems to be a legit issue. Will investigate.
This reverts commit 72153f95ee4c1b52d2f4f483f0ea4f650ec863be.
llvm-svn: 373687
|
|
|
|
|
|
| |
warning: unused variable 'py_func_obj' [-Wunused-variable]
PyObject *py_func_obj = m_py_obj;
llvm-svn: 373686
|
|
|
|
|
|
|
|
|
| |
We previously failed to treat an array with an instantiation-dependent
but not value-dependent bound as being an instantiation-dependent type.
We now track the array bound expression as part of a constant array type
if it's an instantiation-dependent expression.
llvm-svn: 373685
|
|
|
|
|
|
| |
r373682 committed wrong experimental version
llvm-svn: 373684
|
|
|
|
|
|
|
|
|
|
| |
The lambda is taking the stack-allocated Verify boolean by reference and
it would go out of scope on the next iteration. Moving it out of the
loop should fix the issue.
Fixes https://bugs.llvm.org/show_bug.cgi?id=43549
llvm-svn: 373683
|
|
|
|
| |
llvm-svn: 373682
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Fixes https://github.com/google/oss-fuzz/issues/2836
Reviewers: eugenis
Subscribers: dberris, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D68178
llvm-svn: 373681
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
I found a case where the main android binary (app_process32) had thumb code at its entry point but no entry in the symbol table indicating this. This made lldb set a 4 byte breakpoint at that address (we default to arm code) instead of a 2 byte one (like we should for thumb).
The big deal with this is that the expression evaluator uses the entry point as a way to know when a JITed expression has finished executing by putting a breakpoint there. Because of this, evaluating expressions on certain android devices (Google Pixel something) made the process crash.
This was fixed by checking this specific situation when we parse the symbol table and add an artificial symbol for this 2 byte range and indicating that it's arm thumb.
I created 2 unit tests for this, one to check that now we know that the entry point is arm thumb, and the other to make sure we didn't change the behaviour for arm code.
I also run the following on the command line with the `app_process32` where I found the issue:
**Before:**
```
(lldb) dis -s 0x1640 -e 0x1644
app_process32[0x1640]: .long 0xf0004668 ; unknown opcode
```
**After:**
```
(lldb) dis -s 0x1640 -e 0x1644
app_process32`:
app_process32[0x1640] <+0>: mov r0, sp
app_process32[0x1642]: andeq r0, r0, r0
```
Reviewers: clayborg, labath, wallace, espindola
Subscribers: srhines, emaste, arichardson, kristof.beyls, MaskRay, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68069
llvm-svn: 373680
|
|
|
|
|
|
|
|
|
| |
PyClass_Check and everything it relied on seems gone from Python3.7. So
I won't check whether it is a class first...
Also cleaned up a couple of warnings.
llvm-svn: 373679
|
|
|
|
|
|
|
|
|
|
|
| |
named functions in ThinLTO modules.
Without this we can encounter link errors or incorrect behaviour
at runtime as a result of the wrong function being referenced.
Differential Revision: https://reviews.llvm.org/D67945
llvm-svn: 373678
|
|
|
|
|
|
| |
I think that's what is confusing the modules build on the bots.
llvm-svn: 373677
|
|
|
|
|
|
| |
non-x86
llvm-svn: 373676
|
|
|
|
|
|
|
|
|
|
| |
This will allow us to write reusable scripted ThreadPlans, since
you can use key/value pairs with known keys in the plan to parametrize
its behavior.
Differential Revision: https://reviews.llvm.org/D68366
llvm-svn: 373675
|
|
|
|
| |
llvm-svn: 373674
|
|
|
|
|
|
|
|
|
|
| |
Use this in the scripted breakpoint command. Added some tests for parsing
the key/value options. This uncovered a bug in handling parsing errors mid-line.
I also fixed that bug.
Differential Revision: https://reviews.llvm.org/D68363
llvm-svn: 373673
|
|
|
|
| |
llvm-svn: 373672
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
rL371826 rearranged some output from llvm-objdump for GNU objdump compatability, but there still seem to be some more.
I think this rearrangement is a little closer. Overview of the ordering which matches GNU objdump:
* Archive headers
* File headers
* Section headers
* Symbol table
* Dwarf debugging
* Relocations (if `--disassemble` is not used)
* Section contents
* Disassembly
Reviewers: jhenderson, justice_adams, grimar, ychen, espindola
Reviewed By: jhenderson
Subscribers: aprantl, emaste, arichardson, jrtc27, atanasyan, seiya, llvm-commits, MaskRay
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68066
llvm-svn: 373671
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Now that `process list` works better on the android platform, the arch aarch64-unknown-linux-android appears quite often.
The existing printed width of the TRIPLE column is not long enough, which doesn't look okay.
E.g.
```
1561 1016 aarch64-unknown-linux-android ip6tables-restore
1999 1 aarch64-unknown-linux-android tlc_server
2332 982 com.android.systemui
2378 983 webview_zygote
```
Now, after adding 6 spaces, it looks better
```
PID PARENT USER TRIPLE NAME
====== ====== ========== ============================== ============================
...
1561 1016 aarch64-unknown-linux-android ip6tables-restore
1999 1 aarch64-unknown-linux-android tlc_server
2332 982 com.android.systemui
2378 983 webview_zygote
2448 982 com.sec.location.nsflp2
```
Reviewers: clayborg, labath, xiaobai, aadsm
Reviewed By: labath
Subscribers: srhines, kristof.beyls, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68291
llvm-svn: 373670
|
|
|
|
|
|
| |
Fixes the comment in https://reviews.llvm.org/D67993
llvm-svn: 373669
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This replaces the hard coded path.
Reviewers: labath, mgorny
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67993
llvm-svn: 373668
|
|
|
|
|
|
|
|
| |
The static analyzer is warning about potential null dereferences, but we should be able to use castAs<> directly and if not assert will fire for us.
We can also remove a number of explicit asserts and reply on the internal asserts in castAs<>
llvm-svn: 373667
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As discussed on llvm-dev and:
https://bugs.llvm.org/show_bug.cgi?id=43542
...we have transforms that assume shift operations are legal and transforms to
use them are profitable, but that may not hold for simple targets.
In this case, the MSP430 target custom lowers shifts by repeating (many)
simpler/fixed ops. That can be avoided by keeping this code as setcc/select.
Differential Revision: https://reviews.llvm.org/D68397
llvm-svn: 373666
|
|
|
|
|
|
|
|
|
|
| |
getAs<FunctionProtoType> null dereference warning. NFCI.
The static analyzer is warning about a potential null dereference, but we should be able to use castAs<FunctionProtoType> directly and if not assert will fire for us.
Also replaces an auto to make the type more obvious.
llvm-svn: 373665
|
|
|
|
|
|
|
|
|
|
|
| |
doing so in cmake
Move the write-if-changed logic behind a flag and don't pass it
with the MSVC generator. msbuild doesn't have a restat optimization,
so not doing write-if-change there doesn't have a cost, and it
should fix whatever causes PR43385.
llvm-svn: 373664
|
|
|
|
|
|
| |
loclist emission
llvm-svn: 373663
|
|
|
|
|
|
|
| |
ShellExpandArguments is unimplemented on Linux. I need to come up with
another way to test this on Linux.
llvm-svn: 373662
|
|
|
|
|
|
|
|
| |
If the context selector has associated score and several contexts
selectors matches current context, the function with the highest score
must be selected.
llvm-svn: 373661
|
|
|
|
|
|
|
|
| |
The reland uses a static library, not an object library.
Doesn't really matter for the gn build, but it's probalby
nice to have the same semantics for the target type.
llvm-svn: 373660
|
|
|
|
| |
llvm-svn: 373659
|
|
|
|
|
|
| |
The IR was using a fixed 8 byte alignment, but the MIR portion was using native alignment. Since the test doesn't appear to be deliberately testing overalignment, just make the IR match the MIR.
llvm-svn: 373658
|
|
|
|
|
|
|
| |
https://reviews.llvm.org/rL373600 added an AArch64 testcase in top dir
which should be moved to Codegen dir.
llvm-svn: 373657
|
|
|
|
|
|
|
|
| |
There's no need to wrap the just-constructed json::Array in a
json::Value, we can just return that and pass ownership to the
raw_ostream.
llvm-svn: 373656
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fixes pr/42576.
Link: https://github.com/ClangBuiltLinux/linux/issues/697
Reviewers: t.p.northover
Reviewed By: t.p.northover
Subscribers: kristof.beyls, hiraditya, llvm-commits, srhines
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68356
llvm-svn: 373655
|
|
|
|
|
|
| |
373551 relanded in 373651.
llvm-svn: 373654
|
|
|
|
|
|
|
|
|
|
|
|
| |
The first commit removed the workaround in a old script.
This patch removes it in the file actually used by the bots.
I have no idea if this is still needed, but removing the
workaround seems like the easiest way to test.
I'll revert this change if the bots go red.
llvm-svn: 373653
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is follow up patch of https://reviews.llvm.org/D67595.
Adjust naming and the Commutable operands for additional patterns
to make it easier to read.
The testcase update also show that we can save some unecessary fmr as
well.
Reviewers: #powerpc, steven.zhang, hfinkel, nemanjai
Reviewed By: #powerpc, nemanjai
Subscribers: wuzish, hiraditya, kbarton, MaskRay, shchenz, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68112
llvm-svn: 373652
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This will handle expansion of C++ fragments in the declarative combiner
including custom predicates, and escapes into C++ to aid the migration
effort.
Fixed the -DLLVM_LINK_LLVM_DYLIB=ON using DISABLE_LLVM_LINK_LLVM_DYLIB when
creating the library. Apparently it automatically links to libLLVM.dylib
and we don't want that from tablegen.
Reviewers: bogner, volkan
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68288
> llvm-svn: 373551
llvm-svn: 373651
|
|
|
|
|
|
|
|
|
| |
I have no idea if this is still needed, but removing the
workaround seems like the easiest way to test.
I'll revert this change if the bots go red.
llvm-svn: 373650
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D68300
llvm-svn: 373649
|
|
|
|
|
|
|
|
|
|
| |
of 'typeid'.
This is a rare place where it's valid for a function type to be
substituted but not valid for a qualified function type to be
substituted, so needs a special check.
llvm-svn: 373648
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Change the BraceWrappingFlags' AfterControlStatement from a bool to an enum with three values:
* "Never": This is the default, and does not do any brace wrapping after control statements.
* "MultiLine": This only wraps braces after multi-line control statements (this really only happens when a ColumnLimit is specified).
* "Always": This always wraps braces after control statements.
The first and last options are backwards-compatible with "false" and "true", respectively.
The new "MultiLine" option is useful for when a wrapped control statement's indentation matches the subsequent block's indentation. It makes it easier to see at a glance where the control statement ends and where the block's code begins. For example:
```
if (
foo
&& bar )
{
baz();
}
```
vs.
```
if (
foo
&& bar ) {
baz();
}
```
Short control statements (1 line) do not wrap the brace to the next line, e.g.
```
if (foo) {
bar();
} else {
baz();
}
```
Reviewers: sammccall, owenpan, reuk, MyDeveloperDay, klimek
Reviewed By: MyDeveloperDay
Subscribers: MyDeveloperDay, cfe-commits
Patch By: mitchell-stellar
Tags: #clang-format, #clang, #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D68296
llvm-svn: 373647
|
|
|
|
| |
llvm-svn: 373646
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
truncated to v4i8 and concatenated into the lower 8 bytes with undef/zero upper bytes.
This patch recognizes the shuffle pattern we get from a
v8i64->v8i8 truncate when v8i64 isn't a legal type.
With VLX we can use two VTRUNCs, unpckldq, and a insert_subvector.
Diffrential Revision: https://reviews.llvm.org/D68374
llvm-svn: 373645
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLDB handles shell expansion by running lldb-argdumper under a shell.
Currently, this is always /bin/sh on POSIX. This potentially leads to
different behavior between lldb and the user's current shell. Here's an
example of different expansions between shells:
$ /bin/bash -c 'echo -config={Options:[{key:foo_key,value:foo_value}]}'
-config={Options:[key:foo_key]} -config={Options:[value:foo_value]}
$ /bin/zsh -c 'echo -config={Options:[{key:foo_key,value:foo_value}]}'
zsh:1: no matches found: -config={Options:[key:foo_key]}
$ /bin/sh -c 'echo -config={Options:[{key:foo_key,value:foo_value}]}'
-config={Options:[key:foo_key]} -config={Options:[value:foo_value]}
$ /bin/fish -c 'echo -config={Options:[{key:foo_key,value:foo_value}]}'
-config=Options:[key:foo_key] -config=Options:[value:foo_value]
To reduce surprises, this patch returns the user's current shell. It
first looks at the SHELL environment variable. If that isn't set, it'll
ask for the user's default shell. Only if that fails, we'll fallback to
/bin/sh, which should always be available.
Differential revision: https://reviews.llvm.org/D68316
llvm-svn: 373644
|
|
|
|
|
|
|
|
| |
it's instantiation-dependent, even if it's not dependent.
There might be a SFINAE check in the parameter type.
llvm-svn: 373643
|
|
|
|
| |
llvm-svn: 373642
|
|
|
|
|
|
|
|
|
|
| |
We can make use of the Zeroable mask to indicate which elements we can safely set to zero instead of creating a target shuffle mask on the fly.
This only leaves one user of createTargetShuffleMask which we can hopefully get rid of in a similar manner.
This is part of the work to fix PR43024 and allow us to use SimplifyDemandedElts to simplify shuffle chains - we need to get to a point where the target shuffle masks isn't adjusted by its source inputs in setTargetShuffleZeroElements but instead we cache them in a parallel Zeroable mask.
llvm-svn: 373641
|
|
|
|
|
|
|
|
|
| |
This should fix the build bots:
error: declaration of ‘llvm::dsymutil::LinkOptions
DsymutilOptions::LinkOptions’ [-fpermissive]
llvm-svn: 373640
|
|
|
|
| |
llvm-svn: 373639
|
|
|
|
|
|
|
|
| |
Register indexing 64-bit elements is possible on the SALU, but not the
VALU. Handle splitting this into two 32-bit indexes. Extend waterfall
loop handling to allow moving a range of instructions.
llvm-svn: 373638
|