| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 270809
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
objective-c properties.
This fixes an assert in CodeGen that fires when the getter and setter
functions for an objective-c property of type _Atomic(_Bool) are
synthesized.
rdar://problem/26322972
Differential Revision: http://reviews.llvm.org/D20407
llvm-svn: 270808
|
|
|
|
|
|
| |
private.
llvm-svn: 270807
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
directives
If there is already debug info in the assembly file, and user hope to
use -g option for compiling, we think we should not directly report an
error.
According to what GNU assembler did, it just reused the debug info in
the assembly file, and turned off the DEBUG_TYPE option so that there
will be no new debug info emitted by assembler. This fix is just as what
GNU assembler did.
The concern is the situation that there are two .text sections in the
assembly file, one with debug info and the other one without. Currently
with this fix, the assembler will no longer generate any debug info for
the second .text section. And this is what GNU assembler exactly did for
this situation. So I think this still make some sense.
Patch by Zhizhou Yang!
Differential Revision: http://reviews.llvm.org/D20002
llvm-svn: 270806
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After this change, we do the expected thing for cases like
```
Check0Passed = /* range check IRCE can optimize */
Check1Passed = /* range check IRCE can optimize */
if (!(Check0Passed && Check1Passed))
throw_Exception();
```
llvm-svn: 270804
|
|
|
|
|
|
|
|
|
|
|
| |
uint32_t SBProcess::GetNumQueues();
SBQueue SBProcess::GetQueueAtIndex (size_t index);
Otherwise this code will run when the process is running and cause problems.
<rdar://problem/26482744>
llvm-svn: 270803
|
|
|
|
|
|
|
| |
This will later hold more general logic to parse conjunctions of range
checks.
llvm-svn: 270802
|
|
|
|
|
|
|
| |
After r270775, Clang is smarter about the generating the locations for
member-function calls. Update some ubsan tests accordingly.
llvm-svn: 270801
|
|
|
|
|
|
|
| |
This should have been committed with the previous commit, but
I forgot to `git add`. Sorry.
llvm-svn: 270800
|
|
|
|
|
|
|
| |
This text was accidentally left in when the original document was copied from
Chapter 7 of the Kaleidoscope language series.
llvm-svn: 270799
|
|
|
|
| |
llvm-svn: 270798
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of later inputs
Richard Smith identified this in post commit review of r270466. The
string sections in particular (in the future, possibly all sections - so
I'm not going to bother pulling out just the string sections for the
extra lifetime handling right now) need to remain valid during
processing of all inputs so that elements of the DWPStringPool can be
looked up repeatedly without having to make in-memory copies of string
contents in the noncompressed case (more common in dwp+dwp merge steps
where the memory is a bigger problem because the files are larger).
Using the SmallVector (or any vector) a reallocation on push_back could
cause any of the nested SmallStrings in small mode to move in memory and
invalid pointers to their contents. Using a deque the SmallStrings will
never move around since no elements are removed from the container.
llvm-svn: 270797
|
|
|
|
|
|
|
|
|
| |
series.
The original name was pretty long, and likely to look awkward as more
chapters get added.
llvm-svn: 270796
|
|
|
|
|
|
| |
This reverts commit r270786, it causes the directive_fill.s to fail.
llvm-svn: 270795
|
|
|
|
|
|
| |
tutorial.
llvm-svn: 270794
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
T x;
U y;
doing
x = *((T*)y)
is undefined behavior, even if sizeof(T) == sizeof(U), due to pointer aliasing rules
Fix up a couple of places in LLDB that were doing this, and transform them into a defined and safe memcpy() operation
Also, add a test case to ensure we didn't regress by doing this w.r.t. tagged pointer NSDate instances
llvm-svn: 270793
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This allows the linker to discard unused symbol information for comdat
functions that were discarded during the link. Before this change,
searching for the name of an inline function in the debugger would
return multiple results, one per symbol subsection in the object file.
After this change, there is only one result, the result for the function
chosen by the linker.
Reviewers: zturner, majnemer
Subscribers: aaboud, amccarth, llvm-commits
Differential Revision: http://reviews.llvm.org/D20642
llvm-svn: 270792
|
|
|
|
|
|
|
|
|
|
| |
When we have "Image Info Version" module flag but don't have "Class Properties"
module flag, set "Class Properties" module flag to 0, so we can correctly emit
errors when one module has the flag set and another module does not.
rdar://26469641
llvm-svn: 270791
|
|
|
|
|
|
|
|
|
|
|
|
| |
analyses.
Reviewers: tra
Subscribers: jholewinski, llvm-commits
Differential Revision: http://reviews.llvm.org/D20585
llvm-svn: 270790
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: rnk
Subscribers: llvm-commits, tra
Differential Revision: http://reviews.llvm.org/D20494
llvm-svn: 270789
|
|
|
|
| |
llvm-svn: 270788
|
|
|
|
| |
llvm-svn: 270787
|
|
|
|
|
|
|
|
|
| |
This matches the behavior of GNU assembler which supports symbolic
expressions in absolute expressions used in assembly directives.
Differential Revision: http://reviews.llvm.org/D20337
llvm-svn: 270786
|
|
|
|
| |
llvm-svn: 270785
|
|
|
|
|
|
|
|
|
|
| |
r270781 introduced the ability to track whether or not we might have
had unmodeled side-effects during constant expression evaluation. This
patch makes the constexpr evaluator use that tracking.
Reviewed as a part of D18540.
llvm-svn: 270784
|
|
|
|
| |
llvm-svn: 270783
|
|
|
|
| |
llvm-svn: 270782
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the constexpr evaluator is very conservative about unmodeled
side-effects when we're evaluating an expression in a mode that allows
such side-effects.
This patch makes us note when we might have actually encountered an
unmodeled side-effect, which allows us to be more accurate when we know
an unmodeled side-effect couldn't have occurred.
This patch has been split into two commits; this one primarily
introduces the bits necessary to track whether we might have potentially
hit such a side-effect. The one that actually does the tracking (which
boils down to more or less a rename of keepEvaluatingAfterFailure to
noteFailure) is coming soon.
Differential Revision: http://reviews.llvm.org/D18540
llvm-svn: 270781
|
|
|
|
|
|
|
|
| |
TestBSDArchives.py and TestWatchLocation.py fail due to unicode error and bug has already been reported for arm and macOSx.
TestConstVariables.py fails because lldb cant figure out frame variable type when used in expr.
llvm-svn: 270780
|
|
|
|
| |
llvm-svn: 270779
|
|
|
|
|
|
| |
method to Chapter1 of the BuildingAJIT tutorial.
llvm-svn: 270778
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a we have (a) a GEP and (b) a pointer based on an alloca, and the
beginning of the object the GEP points would have a negative offset with
repsect to the alloca, then the GEP can not alias pointer (b).
For example, consider code like:
struct { int f0, int f1, ...} foo;
...
foo alloca;
foo *random = bar(alloca);
int *f0 = &alloca.f0
int *f1 = &random->f1;
Which is lowered, approximately, to:
%alloca = alloca %struct.foo
%random = call %struct.foo* @random(%struct.foo* %alloca)
%f0 = getelementptr inbounds %struct, %struct.foo* %alloca, i32 0, i32 0
%f1 = getelementptr inbounds %struct, %struct.foo* %random, i32 0, i32 1
Assume %f1 and %f0 alias. Then %f1 would point into the object allocated
by %alloca. Since the %f1 GEP is inbounds, that means %random must also
point into the same object. But since %f0 points to the beginning of %alloca,
the highest %f1 can be is (%alloca + 3). This means %random can not be higher
than (%alloca - 1), and so is not inbounds, a contradiction.
Differential Revision: http://reviews.llvm.org/D20495
llvm-svn: 270777
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch modifies the LiveDebugValues pass to use more efficient set
data structures as outlined in PR26055. Both VarLocSet and VarLocList are
now SparseBitVectors which allows us to perform much faster bitvector
arithmetic on them.
The speedup can be in the order of minutes especially on ASANified code.
The change is not NFC in the assembler output because the inserted
DBG_VALUEs are now sorted by variable and location.
Many thanks to Daniel Berlin for helping design the improved algorithm and
reviewing the patch.
https://llvm.org/bugs/show_bug.cgi?id=26055
http://reviews.llvm.org/D20178
rdar://problem/24091200
llvm-svn: 270776
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the callee has a valid location (not all do), then use that. Otherwise, fall
back to the starting location. This makes sure that the debug info for calls
points to the call (not the start of the expression providing the object on
which the member function is being called).
For example, given this:
f->foo()->bar();
we don't want both calls to point to the 'f', but rather to the 'foo()' and
the 'bar()'.
Fixes PR27567.
Differential Revision: http://reviews.llvm.org/D19708
llvm-svn: 270775
|
|
|
|
|
|
|
| |
const' variable. That variable might be defined as 'constexpr', so we cannot
prove that a use of it could never be a constant expression.
llvm-svn: 270774
|
|
|
|
| |
llvm-svn: 270773
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Getting accurate locations for loops is important, because those locations are
used by the frontend to generate optimization remarks. Currently, optimization
remarks for loops often appear on the wrong line, often the first line of the
loop body instead of the loop itself. This is confusing because that line might
itself be another loop, or might be somewhere else completely if the body was
an inlined function call. This happens because of the way we find the loop's
starting location. First, we look for a preheader, and if we find one, and its
terminator has a debug location, then we use that. Otherwise, we look for a
location on an instruction in the loop header.
The fallback heuristic is not bad, but will almost always find the beginning of
the body, and not the loop statement itself. The preheader location search
often fails because there's often not a preheader, and even when there is a
preheader, depending on how it was formed, it sometimes carries the location of
some preceeding code.
I don't see any good theoretical way to fix this problem. On the other hand,
this seems like a straightforward solution: Put the debug location in the
loop's llvm.loop metadata. When emitting debug information, this commit causes
us to add the debug location as an operand to each loop's llvm.loop metadata.
Thus, we now generate this metadata for all loops (not just loops with
optimization hints) when we're otherwise generating debug information.
The remark test case changes depend on the companion LLVM commit r270771.
llvm-svn: 270772
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Getting accurate locations for loops is important, because those locations are
used by the frontend to generate optimization remarks. Currently, optimization
remarks for loops often appear on the wrong line, often the first line of the
loop body instead of the loop itself. This is confusing because that line might
itself be another loop, or might be somewhere else completely if the body was
inlined function call. This happens because of the way we find the loop's
starting location. First, we look for a preheader, and if we find one, and its
terminator has a debug location, then we use that. Otherwise, we look for a
location on an instruction in the loop header.
The fallback heuristic is not bad, but will almost always find the beginning of
the body, and not the loop statement itself. The preheader location search
often fails because there's often not a preheader, and even when there is a
preheader, depending on how it was formed, it sometimes carries the location of
some preceeding code.
I don't see any good theoretical way to fix this problem. On the other hand,
this seems like a straightforward solution: Put the debug location in the
loop's llvm.loop metadata. A companion Clang patch will cause Clang to insert
llvm.loop metadata with appropriate locations when generating debugging
information. With these changes, our loop remarks have much more accurate
locations.
Differential Revision: http://reviews.llvm.org/D19738
llvm-svn: 270771
|
|
|
|
|
|
| |
the creation of synthetic children
llvm-svn: 270770
|
|
|
|
| |
llvm-svn: 270769
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since r268966 the modern Verifier pass defaults to stripping invalid debug info
in nonasserts builds. This patch ports this behavior back to the legacy
Verifier pass as well. The primary motivation is that the clang frontend
accepts bitcode files as input but is still using the legacy pass pipeline.
Background: The problem I'm trying to solve with this sequence of patches is
that historically we've done a really bad job at verifying debug info. We want
to be able to make the verifier stricter without having to worry about breaking
bitcode compatibility with existing producers. For example, we don't necessarily
want IR produced by an older version of clang to be rejected by an LTO link just
because of malformed debug info, and rather provide an option to strip it. Note
that merely outdated (but well-formed) debug info would continue to be
auto-upgraded in this scenario.
http://reviews.llvm.org/D20629
<rdar://problem/26448800>
llvm-svn: 270768
|
|
|
|
|
|
| |
Equivalent tests included in sse41-intrinsics-x86-upgrade.ll - the i8/i32 immediate diff doesn't matter anymore
llvm-svn: 270767
|
|
|
|
| |
llvm-svn: 270766
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
inference in LTO pipeline.
As a result of D18634 we no longer infer certain attributes on linkonce_odr
functions at compile time, and may only infer them at LTO time. The readnone
attribute in particular is required for virtual constant propagation (part
of whole-program virtual call optimization) to work correctly.
This change moves the whole-program virtual call optimization pass after
the function attribute inference passes, and enables the attribute inference
passes at opt level 1, so that virtual constant propagation has a chance to
work correctly for linkonce_odr functions.
Differential Revision: http://reviews.llvm.org/D20643
llvm-svn: 270765
|
|
|
|
| |
llvm-svn: 270764
|
|
|
|
|
|
| |
My script missed those in r270750.
llvm-svn: 270763
|
|
|
|
|
|
|
|
|
| |
The max warning check was masking the "return 0" codepath.
See the thread "Warnings and compile-time failure on 458.sjeng" for more
info.
llvm-svn: 270762
|
|
|
|
|
|
| |
Equivalent tests included in sse41-intrinsics-x86-upgrade.ll
llvm-svn: 270761
|
|
|
|
| |
llvm-svn: 270760
|
|
|
|
|
|
|
|
|
|
| |
It may materialize a declaration, or a definition. The name could
be misleading. This is following a merge of materializeInitFor()
into materializeDeclFor().
Differential Revision: http://reviews.llvm.org/D20593
llvm-svn: 270759
|