As loads are combined and widened, we replaced their sext users
operands whereas we should have been replacing the uses of the sext.
I've added a load of tests, with only a few of them originally
causing assertion failures, the rest improve pattern coverage.
Differential Revision: https://reviews.llvm.org/D65740
llvm-svn: 368404
Summary:
printTemplateSpecializationArgs was not printing partial variable specialization args. This adds an additional If clause where we check if it's a VariableTemplatePartialSpecializationDecl and returns the ArgumentLocs if that's the case.
Also adds tests for printTemplateSpecializationArgs in ASTTests.cpp.
Reviewers: hokein, ilya-biryukov
Subscribers: MaskRay, jkorous, arphaman, kadircet, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D65926
llvm-svn: 368403
Summary:
Clang generates function bodies and puts them in the AST for default methods if it is defaulted outside the class definition.
`
struct A {
A &operator=(A &&O);
};
A &A::operator=(A &&O) = default;
`
This will generate a function body for the `A &A::operator=(A &&O)` and put it in the AST. This body should not be visited if implicit code is not visited as it is implicit.
This was causing SemanticHighlighting in clangd to generate duplicate tokens and putting them in weird places.
Reviewers: hokein, ilya-biryukov, gribozavr
Subscribers: mgorny, jkorous, arphaman, kadircet, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D65938
llvm-svn: 368402
Summary:
Make sure that we report that changes has been made
by InstSimplify also in situations when only trivially
dead instructions has been removed. If for example a call
is removed the call graph must be updated.
Bug seem to have been introduced by llvm-svn r367173
(commit 02b9e45a7e), since the code in question
was rewritten in that commit.
Reviewers: spatel, chandlerc, foad
Reviewed By: spatel
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65973
llvm-svn: 368401
The only way to generate these was through promoting legalization
of narrow vectors, but we widen those types now. So we shouldn't
produce these nodes.
llvm-svn: 368396
I am working to remove this concept of the "FinalPhase" in the clang driver,
but it is used in a lot of different places to do argument handling for
different combinations of phase pipelines and arguments. I am trying to
consolidate most of the uses of "FinalPhase" into its own separate scope.
Eventually, in a subsequent patch I will move all of this stuff to a separate
function, and have more of the complication phase list construction setup into
types::getComplicationPhases.
Differential Revision: https://reviews.llvm.org/D65969
llvm-svn: 368393
Port existing headers which include x86 intrinsics implementation to
PowerPC platform (using Altivec), along with tests. Also, tests about
including these intrinsic headers are combined.
The headers are mainly developed by Steven Munroe, with contributions
from Paul Clarke, Bill Schmidt, Jinsong Ji and Zixuan Wu.
Reviewed By: Jinsong Ji
Differential Revision: https://reviews.llvm.org/D65630
llvm-svn: 368392
Summary:
A condition could be a multi-line expression where we create the highlight
in separated chunks. PathDiagnosticPopUpPiece is not made for that purpose,
it cannot be added to multiple lines because we have only one ending part
which contains all the notes. So that it cannot have multiple endings and
therefore this patch narrows down the ranges of the highlight to the given
interesting variable of the condition. It prevents HTML-breaking injections.
Reviewed By: NoQ
Differential Revision: https://reviews.llvm.org/D65663
llvm-svn: 368382
If the dot gets moved by an explicit section address, an empty gap between sections could be created. The encompassing region for the section being parsed needs to be expanded to include the gap.
Differential Revision: https://reviews.llvm.org/D65722
Patch by Gabriel Smith!
llvm-svn: 368379
This ensures these errors produce a non-zero exit and improves the
context (providing the name of the input object and section being
parsed).
llvm-svn: 368378
This isn't the most robust error handling API, but does allow clients to
opt-in to getting Errors they can handle. I suspect the long-term
solution would be to move away from the lazy unit parsing and have an
explicit step that parses the unit and then allows access to the other
APIs that require a parsed unit.
llvm-dwarfdump could be expanded to use this (or newer/better API) to
demonstrate the benefit of it - but for now lld will use this in a
follow-up cl which ensures lld can exit non-zero on errors like this (&
provide more descriptive diagnostics including which object file the
error came from).
(error access to later errors when parsing nested DIEs would be good too
- but, again, exposing that without it being a hassle for every consumer
may be tricky)
llvm-svn: 368377
In the case where C identifier sections have SHF_LINK_ORDER they will most
likely be placed in the same partition as the section that they are associated
with. But unless this happens to be the main partition, this will cause them
to be excluded from the range covered by the __start_ and __stop_ symbols,
which may lead to incorrect program behaviour. So we need to move them
all into the main partition so that they will be covered by the __start_
and __stop_ symbols.
We may want to refine this approach later and allow different __start_/__stop_
symbol values for different partitions. This would only make sense for
relocations from SHT_NOTE sections since they are duplicated into each
partition.
Differential Revision: https://reviews.llvm.org/D65909
llvm-svn: 368375
Summary:
This bug occurred when a plug-in requested that a binary not be
symbolized while the script is trying to symbolize a stack frame. In
this case `self.frame_no` would not be incremented. This would cause
subsequent stack frames that are symbolized to be incorrectly numbered.
To fix this `get_symbolized_lines()` has been modified to take an
argument that indicates whether the stack frame counter should
incremented. In `process_line_posix()` `get_symbolized_lines(None, ...)`
is now used in in the case where we don't want to symbolize a line so
that we can keep the frame counter increment in a single function.
A test case is included. The test uses a dummy plugin that always asks
`asan_symbolize.py` script to not symbolize the first binary that the
script asks about. Prior to the patch this would cause the output to
script to look something like
```
#0 0x0
#0 0x0 in do_access
#1 0x0 in main
```
rdar://problem/49476995
Reviewers: kubamracek, yln, samsonov, dvyukov, vitalybuka
Subscribers: #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D65495
llvm-svn: 368373
Summary:
Emscripten expects `__data_end` to show up in PIC code as long as it's not
linked with `--shared`.
Currently, Emscripten breaks with latest LLVM because `__data_end` is controlled
by `config->isPic` instead of `config->shared`.`
Reviewers: tlively, sbc100
Reviewed By: sbc100
Subscribers: dschuff, jgravelle-google, aheejin, sunfish, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65980
llvm-svn: 368361
GlobalAlias and GlobalIFunc ought to be treated the same by the IR
linker, so we can generalize the code to be in terms of their common
base class GlobalIndirectSymbol.
Differential Revision: https://reviews.llvm.org/D55046
llvm-svn: 368357
Summary:
This test doesn't make sense. Change to be consistent with what we did
in GDBRemoteCommunication.cpp.
Reviewers: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D65965
llvm-svn: 368352
See D65364 for the code model requirements for tagged globals. Because
of the relocations used these requirements cannot be checked at link
time so they must be checked at runtime.
Differential Revision: https://reviews.llvm.org/D65968
llvm-svn: 368351
Under this configuration we'll want to split the v8i64 or v16i32 into two vectors. The default legalization will try to truncate each of those 256-bit pieces one step to 128-bit, concatenate those, then truncate one more time from the new 256 to 128 bits.
With this patch we now truncate the two splits to 64-bits then concatenate those. We have to do this two different ways depending on whether have widening legalization enabled. Without widening legalization we have to manually construct X86ISD::VTRUNC to prevent the ISD::TRUNCATE with a narrow result being promoted to 128 bits with a larger element type than what we want followed by something like a pshufb to grab the lower half of each element to finish the job. With widening legalization we just get the right thing. When we switch to widening by default we can just delete the other code path.
Differential Revision: https://reviews.llvm.org/D65626
llvm-svn: 368349
Apparently Windows returns the "invalid argument" error code when the
path contains invalid characters such as '<'. The
test/Preprocessor/include-likely-typo.c test does this, so it was
failing after r368322.
Also, the diagnostic requires two arguments, so add the filename.
llvm-svn: 368348
When looking up a type by name, also scan through any referenced Clang
modules regardsless of whether a type with this name has been
found. This is NFCish (= a potential performance regression) for Clang
projects, but necessary in mixed Swift and Objective-C projects (and
tested in swift-lldb).
This only affects projects compiled with -gmodules that were not run
through dsymutil.
llvm-svn: 368345
We may be able to look to how VSELECT is handled to further
improve this, but this appears to be neutral or an improvement
on the test cases we have.
llvm-svn: 368344
Raphael Isemann