| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
This patch changes the code to use a modern unwrapOrError(StringRef Input, Expected<T> EO)
version that contains the input source name and removes the deprecated version.
Differential revision: https://reviews.llvm.org/D65946
llvm-svn: 368428
|
|
|
|
| |
llvm-svn: 368425
|
|
|
|
|
|
|
|
|
|
| |
These types were recently added in D62960 but it seems the patch didn't
consider LLDB which causes a bunch of compiler warnings about
missing enum values. It seems this feature isn't fully implemented yet,
so I don't think we can write any test for this. For now lets just add
the missing types to our usual list of unsupported types.
llvm-svn: 368424
|
|
|
|
|
|
|
| |
All TLS access on Darwin is in the "general dynamic" form where we call
a function to resolve the address, so implementation is pretty simple.
llvm-svn: 368418
|
|
|
|
|
|
|
|
| |
Not NFC as this will probably fix a wrong guard variable check
on Windows. Not sure though what Windows test can now be safely
enabled.
llvm-svn: 368417
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When opening a minidump, we were failing to find an executable because
we were searching for i386-unknown-windows, whereas we recognize the
pe/coff files as i386-pc-windows. This fixes the triple computation code
in the minidump parser to match pe/coff, and adds an appropriate test.
NB: I'm not sure setting the vendor to "pc" is really correct for
arm(64) windows, but right now that seems to match what we do in the
pe/coff case (ArchSpec.cpp:935).
Reviewers: clayborg, amccarth
Subscribers: javed.absar, kristof.beyls, rnk, markmentovai, lldb-commits
Differential Revision: https://reviews.llvm.org/D65955
llvm-svn: 368416
|
|
|
|
| |
llvm-svn: 368415
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds the SVE built-in types defined by the Procedure Call
Standard for the Arm Architecture:
https://developer.arm.com/docs/100986/0000
It handles the types in all relevant places that deal with built-in types.
At the moment, some of these places bail out with an error, including:
(1) trying to generate LLVM IR for the types
(2) trying to generate debug info for the types
(3) trying to mangle the types using the Microsoft C++ ABI
(4) trying to @encode the types in Objective C
(1) and (2) are fixed by follow-on patches but (unlike this patch)
they deal mostly with target-specific LLVM details, so seemed like
a logically separate change. There is currently no spec for (3) and
(4), so reporting an error seems like the correct behaviour for now.
The intention is that the types will become sizeless types:
http://lists.llvm.org/pipermail/cfe-dev/2019-June/062523.html
The main purpose of the sizeless type extension is to diagnose
impossible or dangerous uses of the types, such as any that would
require sizeof to have a meaningful defined value.
Until then, the patch sets the alignments of the types to the values
specified in the link above. It also sets the sizes of the types to
zero, which is chosen to be consistently wrong and shouldn't affect
correctly-written code (i.e. code that would compile even with the
sizeless type extension).
The patch adds the common subset of functionality needed to test the
sizeless type extension on the one hand and to provide SVE intrinsic
functions on the other. After this patch, the two pieces of work are
essentially independent.
The patch is based on one by Graham Hunter:
https://reviews.llvm.org/D59245
Differential Revision: https://reviews.llvm.org/D62960
llvm-svn: 368413
|
|
|
|
|
|
|
|
|
|
|
| |
It is outdated. Using of Expected<> is preferred, also it does
not provide a way to report a file name.
I updated the code to use the modern version of unwrapOrError instead.
Differential revision: https://reviews.llvm.org/D65951
llvm-svn: 368410
|
|
|
|
|
|
|
|
|
|
|
|
| |
The filename part in the message header is used by Visual Studio
to fill Error List so that a user can click on an item and jump
to the mentioned location. If we use only the name of a source file
and not the full path, Visual Studio might be unable to find the right
file or, even worse, show a wrong one.
Differential Revision: https://reviews.llvm.org/D65875
llvm-svn: 368409
|
|
|
|
|
|
|
|
|
| |
I've now needed to add an extra parameter to this call twice recently. Not only
is the signature getting extremely unwieldy, but just updating all of the
callsites and implementations is a pain. Putting the parameters in a struct
sidesteps both issues.
llvm-svn: 368408
|
|
|
|
| |
llvm-svn: 368406
|
|
|
|
| |
llvm-svn: 368405
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
specialization arguments.
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
method was default created.
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 02b9e45a7e4b81), 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
|
|
|
|
|
|
|
| |
We shouldn't form trunc stores that need to be expanded now that
we are using widening legalization.
llvm-svn: 368400
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: ASSERT_THAT_ERROR looks like the intended helper for use in tests.
Reviewers: plotfi, jkorous, compnerd
Subscribers: mgorny, dexonsmith, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D65853
llvm-svn: 368399
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: libs can be installed to ../lib64.
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65972
llvm-svn: 368398
|
|
|
|
|
|
|
| |
I believe PR34584 was tracking that FIXME, but its since been
closed and a test case was added.
llvm-svn: 368397
|
|
|
|
|
|
|
|
|
|
| |
masked store.
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
|
|
|
|
|
|
|
|
| |
TypeWidenVector check from code that handles X86ISD::VPMADDWD and X86ISD::AVG.
More unneeded code since we now legalize narrow vectors by widening.
llvm-svn: 368395
|
|
|
|
|
|
| |
This is no longer needed since we widen v2i32 instead of promoting.
llvm-svn: 368394
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
handling in LowerStore now that v2i32 is widened to v4i32.
llvm-svn: 368390
|
|
|
|
|
|
| |
ReplaceNodeResults/LowerMSCATTER now that v2i32 is also widened like v2f32.
llvm-svn: 368389
|
|
|
|
|
|
|
|
| |
ReplaceNodeResults.
We rely on the generic type legalizer for this now.
llvm-svn: 368388
|
|
|
|
|
|
| |
to only handle widening.
llvm-svn: 368387
|
|
|
|
|
|
| |
SIGN_EXTEND/ZERO_EXTEND/TRUNCATE for vectors to only handle widening.
llvm-svn: 368386
|
|
|
|
|
|
| |
vectors to only handle widening.
llvm-svn: 368385
|
|
|
|
|
|
|
|
| |
handling code.
We now widen illegal vector types so we don't need this anymore.
llvm-svn: 368384
|
|
|
|
|
|
|
|
|
|
| |
Summary: Thanks to Kristóf Umann for the great idea!
Reviewed By: NoQ
Differential Revision: https://reviews.llvm.org/D65889
llvm-svn: 368383
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
This only adds support to the minimizer, it doesn't actually capture the dependencies yet.
llvm-svn: 368381
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when parsing units
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
partition.
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: This was a bug in rL368310. I'm working on a test case now.
Differential Revision: https://reviews.llvm.org/D65985
llvm-svn: 368369
|
|
|
|
|
|
| |
Nothing is using the function return.
llvm-svn: 368367
|
|
|
|
| |
llvm-svn: 368364
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D65982
llvm-svn: 368363
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
IRG does not access any memory.
Replace IntrInaccessibleMemOnly with IntrNoMem | IntrHasSideEffects.
Reviewers: chill
Subscribers: javed.absar, kristof.beyls, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64447
llvm-svn: 368362
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 368360
|
|
|
|
| |
llvm-svn: 368359
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Tool parses input IR file, and runs the delta debugging algorithm to reduce the functions inside the input file.
Reviewers: alexshap, chandlerc
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63672
> llvm-svn: 368071
llvm-svn: 368358
|