This fixes a few cases where we'd emit path notes like this:
+---+
1| v
p = malloc(len);
^ |2
+---+
In general this should make path notes more consistent and more correct,
especially in cases where the leak happens on the false branch of an if
that jumps directly to the end of the function. There are a couple places
where the leak is reported farther away from the cause; these are usually
cases where there are several levels of nested braces before the end of
the function. This still matches our current behavior for when there /is/
a statement after all the braces, though.
llvm-svn: 168070
Also, don't bother to stop tracking symbols in the return value, either.
They are now properly considered live during checkDeadSymbols.
llvm-svn: 168069
Also, don't bother to stop tracking symbols in the return value, either.
They are now properly considered live during checkDeadSymbols.
llvm-svn: 168068
Also, don't bother to stop tracking symbols in the return value, either.
They are now properly considered live during checkDeadSymbols.
llvm-svn: 168067
This allows us to properly remove dead bindings at the end of the top-level
stack frame, using the ReturnStmt, if there is one, to keep the return value
live. This in turn removes the need for a check::EndPath callback in leak
checkers.
This does cause some changes in the path notes for leak checkers. Previously,
a leak would be reported at the location of the closing brace in a function.
Now, it gets reported at the last statement. This matches the way leaks are
currently reported for inlined functions, but is less than ideal for both.
llvm-svn: 168066
to a cc1 -fencode-extended-block-signature and pass it
to cc1 and recognize this option to produce extended block
type signature. // rdar://12109031
llvm-svn: 168063
positive.
In this particular case, R6 was being spilled by the register scavenger when it
was in fact dead. The isUsed function reported R6 as used because the R6_R7
alias was reserved (due to the fact that we've reserved R7 as the FP). The
solution is to only check if the original register (i.e., R6) isReserved and
not the aliases. The aliases are only checked to make sure they're available.
The test case is derived from one of the nightly tester benchmarks and is rather
intractable and difficult to reproduce, so I haven't included it.
rdar://12592448
llvm-svn: 168054
Fixed an issue where lldb was setting breakpoints on too many methods when a partial function name with namespaces or class qualifiers was used. For example setting a breakpoint of "Foo::dealloc" was accidentally settings breakpoints on all objective C functions whose selector was "dealloc"...
llvm-svn: 168053
It may become a dangling pointer if the underlying SmallVector reallocates.
Sadly the testcase is really large and doesn't reduce well because of
SmallVector's reallocation patterns.
Fixes PR14336.
llvm-svn: 168045
For global variables that get the same value stored into them
everywhere, GlobalOpt will replace them with a constant. The problem is
that a thread-local GlobalVariable looks like one value (the address of
the TLS var), but is different between threads.
This patch introduces Constant::isThreadDependent() which returns true
for thread-local variables and constants which depend on them (e.g. a GEP
into a thread-local array), and teaches GlobalOpt not to track such
values.
llvm-svn: 168037
the utility for extracting a chain of operations from the IR, thought that it
might as well combine any constants it came across (rather than just returning
them along with everything else). On the other hand, the factorization code
would like to see the individual constants (this is quite reasonable: it is
much easier to pull a factor of 3 out of 2*3 than it is to pull it out of 6;
you may think 6/3 isn't so hard, but due to overflow it's not as easy to undo
multiplications of constants as it may at first appear). This patch therefore
makes LinearizeExprTree stupider: it now leaves optimizing to the optimization
part of reassociate, and sticks to just analysing the IR.
llvm-svn: 168035
more sense anyway - it determines how expressions are codegen'd. It also ensures
that -ffp-contract=fast has the intended effect when compiling LLVM IR.
llvm-svn: 168027
Akira Hatanaka