Previously we weren't skipping the VVVV encoded register. Based on patch by Michael Liao.

llvm-svn: 177221

r175234 allowed the analyzer to model trivial copy/move constructors as
an aggregate bind. This commit extends that to trivial assignment
operators as well. Like the last commit, one of the motivating factors here
is not warning when the right-hand object is partially-initialized, which
can have legitimate uses.

<rdar://problem/13405162>

llvm-svn: 177220

llvm-svn: 177219

Thanks to Richard S. for pointing out that the warning would show up
with -Weverything.

llvm-svn: 177218

llvm-svn: 177217

When we generate a path diagnostic for a bug report, we have to take the
full ExplodedGraph and limit it down to a single path. We do this in two
steps: "trimming", which limits the graph to all the paths that lead to
this particular bug, and "creating the report graph", which finds the
shortest path in the trimmed path to any error node.

With BugReporterVisitor false positive suppression, this becomes more
expensive: it's possible for some paths through the trimmed graph to be
invalid (i.e. likely false positives) but others to be valid. Therefore
we have to run the visitors over each path in the graph until we find one
that is valid, or until we've ruled them all out. This can become quite
expensive.

This commit separates out graph trimming from creating the report graph,
performing the first only once per bug equivalence class and the second
once per bug report. It also cleans up that portion of the code by
introducing some wrapper classes.

This seems to recover most of the performance regression described in my
last commit.

<rdar://problem/13433687>

llvm-svn: 177216

...in favor of this typedef:

  typedef llvm::DenseMap<const ExplodedNode *, const ExplodedNode *>
          InterExplodedGraphMap;

Use this everywhere the previous class and typedef were used.

Took the opportunity to ArrayRef-ize ExplodedGraph::trim while I'm at it.

No functionality change.

llvm-svn: 177215

I removed this check in the recursion->iteration commit, but forgot that
generatePathDiagnostic may be called multiple times if there are multiple
PathDiagnosticConsumers.

llvm-svn: 177214

llvm-svn: 177213

This should be nothing but a load-time optimization.  I'm trying to reduce load time initializers and this is a big one.  No visible functionality change intended.

llvm-svn: 177212

For constructors/desctructors that return 'this', if there exists a callsite
that returns 'this' and is immediately before the return instruction, make
sure we are using the return value from the callsite.

We don't need to keep 'this' alive through the callsite. It also enables
optimizations in the backend, such as tail call optimization.

rdar://12818789

llvm-svn: 177211

Since almost all X86 instructions can fold loads, use a multiclass to
define register/memory pairs of SchedWrites.

An X86FoldableSchedWrite represents the register version of an
instruction. It holds a reference to the SchedWrite to use when the
instruction folds a load.

This will be used inside multiclasses that define rr and rm instruction
versions together.

llvm-svn: 177210

When the template argument is both default and value dependent, the expression
retrieved for the default argument cannot be evaluated, thus never matching
any argument value.  To get the proper value, get the template argument
from the desugared template specialization.  Also, output the original
expression to provide more information about the argument mismatch.

llvm-svn: 177209

Variables view out of sync with lldb in Xcode is now fixed. Depending on what happened stack frames could get out of date and a stale shared pointer (one that is no longer a current frame in a thread) could end up being used. 

Now we don't store a weak_ptr to a frame in the ExecutionContextRef class, we just store its stack ID and we always regrab the frame from the thread by stack ID.

llvm-svn: 177208

llvm-svn: 177207

Fixes a FIXME, improves dead symbol collection, suppresses a false positive,
which resulted from reusing the same symbol twice for simulation of 2 calls to the same function.

Fixing this lead to 2 possible false negatives in CString checker. Since the checker is still alpha and
the solution will not require revert of this commit, move the tests to a FIXME section.

llvm-svn: 177206

llvm-svn: 177205

llvm-svn: 177204

Performance improvements to the IsObjCNil () - we only try to resolve the value if the variable under consideration truly is an “Objective-C thing”
This also changes the ClangASTContext to make sure that id is correctly marked as being such an ObjC thing

llvm-svn: 177203

Don't discount regions that vmmap is not discounting.

llvm-svn: 177202

Fix buffer underrun (invalid read) triggered during diagnostic rendering.  The test would overflow when computing '0 - 1'.

I don't have a good testcase for this that does not depend on system headers.
It did not trigger with preprocessed output, and I had trouble reducing the example.

Fixes <rdar://problem/13324594>.

Thanks to Michael Greiner for reporting this issue.

llvm-svn: 177201

in the -a address expression lookup in "image list" so that it actually works.

llvm-svn: 177200

Don't require instructions to inherit Sched<...>. Sometimes it is more
convenient to say:

  let SchedRW = ... in {
    ...
  }

Which is now possible.

llvm-svn: 177199

llvm-svn: 177198

These will be available in the current translation unit anyway, for
modules they only waste space and deserialization time.

llvm-svn: 177197

llvm-svn: 177196

resolved command, which it should not do.  It should adopt whatever context the
regular expression command was called with.  This was causing regular expression
commands run inside breakpoint commands to adopt the currently selected context,
not the one coming from the breakpoint that we hit.

<rdar://problem/13411771>

llvm-svn: 177195

When we're building a precompiled header or module against an SDK on
Darwin, there will be a file SDKSettings.plist in the sysroot. Since
stat()'ing every system header on which a module or PCH file depends
is performance suicide, we instead stat() just SDKSettings.plist. This
hack works well on Darwin; it's unclear how we want to handle this on
other platforms. If there is a canonical file, we should use it; if
not, we either have to take the performance hit of stat()'ing system
headers repeatedly or roll the dice by not checking anything.

llvm-svn: 177194

llvm-svn: 177193

Patch by Ashok Thirumurthi.

llvm-svn: 177192

This is QoI.  Fixes <rdar://problem/13076064>.

llvm-svn: 177190

The previous generatePathDiagnostic() was intended to be tail-recursive,
restarting and trying again if a report was marked invalid. However:
 (1) this leaked all the cloned visitors, which weren't being deleted, and
 (2) this wasn't actually tail-recursive because some local variables had
     non-trivial destructors.

This was causing us to overflow the stack on inputs with large numbers of
reports in the same equivalence class, such as sqlite3.c. Being iterative
at least prevents us from blowing out the stack, but doesn't solve the
performance issue: suppressing thousands (yes, thousands) of paths in the
same equivalence class is expensive. I'm looking into that now.

<rdar://problem/13423498>

llvm-svn: 177189

We discovered that sqlite3.c currently has 2600 reports in a single
equivalence class; it would be good to know if this is a recent
development or what.

(For the curious, the different reports in an equivalence class represent
the same bug found along different paths. When we're suppressing false
positives, we need to go through /every/ path to make sure there isn't a
valid path to a bug. This is a flaw in our after-the-fact suppression,
made worse by the fact that that function isn't particularly optimized.)

llvm-svn: 177188

For debugging use only; no functionality change.

llvm-svn: 177187

Silences a few false positives in LLVM.

llvm-svn: 177186

No functionality change.

llvm-svn: 177185

This cleans up the Clang -Werror build that was broken by r177180.

llvm-svn: 177184

 - This fast path is almost 100% effective on real code, and lets us avoid
   multiple allocations of 128-bit APSInt objects in the common case.

 - As with any overflow-check-skipping-code, I'd appreciate someone double
   checking my logic.

llvm-svn: 177183

These are a burden to maintain & use hand crafted IR to test particular DWARF
generation cases in LLVM. If someone thinks there's high value coverage here
they can rephrase these as IR+dwarfdump tests in the LLVM regression suite so
they'll be portable/easily executed by all developers.

llvm-svn: 177182

operations. // rdar://13423975

llvm-svn: 177181