| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 66855
|
| |
|
|
|
|
| |
source being a non-pointer.
llvm-svn: 66854
|
| |
|
|
| |
llvm-svn: 66853
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
C++ templates. In particular, keep track of the overloaded operators
that are visible from the template definition, so that they can be
merged with those operators visible via argument-dependent lookup at
instantiation time.
Refactored the lookup routines for argument-dependent lookup and for
operator name lookup, so they can be called without immediately adding
the results to an overload set.
Instantiation of these expressions is completely wrong. I'll work on
that next.
llvm-svn: 66851
|
| |
|
|
| |
llvm-svn: 66850
|
| |
|
|
|
|
|
| |
include the triplet so that people that run multiple targets in
parallel, say i386 and x86_64 can distinguish between the two.
llvm-svn: 66849
|
| |
|
|
|
|
|
| |
print-{multi-{directory,lib,os-directory}, search-dirs} as unsupported
instead of handling separately.
llvm-svn: 66848
|
| |
|
|
|
|
| |
to the stack. This shrinks all llvm tools by 9k, and improves reentrancy.
llvm-svn: 66847
|
| |
|
|
| |
llvm-svn: 66846
|
| |
|
|
| |
llvm-svn: 66845
|
| |
|
|
| |
llvm-svn: 66844
|
| |
|
|
| |
llvm-svn: 66843
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ExplodedGraph::TrimGraph:
- Just do a DFS both ways instead of BFS-DFS. We're just determining what subset
of the nodes are reachable from the root and reverse-reachable from the bug
nodes. DFS is more efficient for this task.
BugReporter:
- MakeReportGraph: Do a reverse-BFS instead of a reverse-DFS to determine the
approximate shortest path through the simulation graph. We were seeing some
weird cases where too many loops were being reported for simple bugs. Possibly
we will need to replace this with actually computing the shortest path in
terms of line numbers.
llvm-svn: 66842
|
| |
|
|
|
|
|
|
| |
right; did the wrong thing when there are exactly 11
non-debug instructions, followed by debug info.
Remove a FIXME since it's apparently been fixed along the way.
llvm-svn: 66840
|
| |
|
|
| |
llvm-svn: 66839
|
| |
|
|
| |
llvm-svn: 66838
|
| |
|
|
| |
llvm-svn: 66837
|
| |
|
|
|
|
|
| |
bitmap generation for basic ivars seem to
work now. This is work in progress.
llvm-svn: 66836
|
| |
|
|
| |
llvm-svn: 66835
|
| |
|
|
|
|
| |
the selector for the property setter.
llvm-svn: 66834
|
| |
|
|
|
|
| |
can more efficiently reconstruct an IntegerLiteral from it during template instantiation
llvm-svn: 66833
|
| |
|
|
|
|
| |
(TypedViewRegion::getLValueType() was not implemented).
llvm-svn: 66830
|
| |
|
|
|
|
| |
single character writes.
llvm-svn: 66827
|
| |
|
|
|
|
|
|
|
|
|
| |
in the Ada testcase. Reverting this only covers up
the real problem, which is a nasty conceptual difficulty
in the phi elimination pass: when eliminating phi nodes
in landing pads, the register copies need to come before
the invoke, not at the end of the basic block which is
too late... See PR3784.
llvm-svn: 66826
|
| |
|
|
| |
llvm-svn: 66825
|
| |
|
|
|
|
| |
sorting of ConstantInt's; unreinvent wheel.
llvm-svn: 66824
|
| |
|
|
|
|
|
|
| |
refers to the "prefix" directory, i.e., one level above "bin". LLVMGCCPATH
is used as the directory containing the llvm-gcc executable, so add a "/bin"
suffix to get from LLVMGCCDIR to LLVMGCCPATH.
llvm-svn: 66823
|
| |
|
|
| |
llvm-svn: 66820
|
| |
|
|
|
|
|
|
|
| |
- Who wouldn't want correctness to hang critically on two easily
ignored characters?
Thanks Doug!
llvm-svn: 66819
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- PathDiagnosticControlFlowPiece now consists of a "start" and "end" location
to indicating the branch location and where the branch goes.
BugReporter:
- Updated BugReporter to construct PathDiagnosticControlFlowPiece objects with
"end" locations.
PlistDiagnostics:
- Plists now contain the bug "type" (not just bug "category")
- Plists now encode control-flow pieces differently than events; now the
"start" and "end" locations are recorded
llvm-svn: 66818
|
| |
|
|
|
|
|
|
|
|
|
| |
- Compare to driverdriver.c if bored; not completely fair since the
driver gets a bit more code in other places to handle binding archs
(for Xarch) but not completely unfair either.
Fear not, extra Action classes will have a happy home for their
vtables soon.
llvm-svn: 66817
|
| |
|
|
|
|
|
| |
instantiation. This is roughly the structure we want to expression
instantiation.
llvm-svn: 66816
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
access each with a fixed negative index from op_end().
This has two important implications:
- getUser() will work faster, because there are less iterations
for the waymarking algorithm to perform. This is important
when running various analyses that want to determine callers
of basic blocks.
- getSuccessor() now runs faster, because the indirection via OperandList
is not necessary: Uses corresponding to the successors are at fixed
offset to "this".
The price we pay is the slightly more complicated logic in the operator
User::delete, as it has to pick up the information whether it has to free
the memory of an original unconditional BranchInst or a BranchInst that
was originally conditional, but has been shortened to unconditional.
I was not able to come up with a nicer solution to this problem. (And
rest assured, I tried *a lot*).
Similar reorderings will follow for InvokeInst and CallInst. After that
some optimizations to pred_iterator and CallSite will fall out naturally.
llvm-svn: 66815
|
| |
|
|
|
|
|
|
| |
be CompoundStmts. I think this is a valid assumption, and felt that the API
should reflect it. Others please validate this assumption to make sure I didn't
break anything.
llvm-svn: 66814
|
| |
|
|
| |
llvm-svn: 66813
|
| |
|
|
| |
llvm-svn: 66809
|
| |
|
|
| |
llvm-svn: 66807
|
| |
|
|
| |
llvm-svn: 66806
|
| |
|
|
| |
llvm-svn: 66805
|
| |
|
|
|
|
| |
assembly. 2. Fixed JIT encoding by making the address pc-relative.
llvm-svn: 66803
|
| |
|
|
| |
llvm-svn: 66801
|
| |
|
|
| |
llvm-svn: 66800
|
| |
|
|
| |
llvm-svn: 66799
|
| |
|
|
| |
llvm-svn: 66798
|
| |
|
|
| |
llvm-svn: 66797
|
| |
|
|
|
|
|
|
|
| |
width of bitfields.
I'll be burning this down and replacing it with a properly-dispatched
implementation like the one used for types.
llvm-svn: 66796
|
| |
|
|
| |
llvm-svn: 66795
|
| |
|
|
| |
llvm-svn: 66794
|
| |
|
|
| |
llvm-svn: 66793
|
| |
|
|
| |
llvm-svn: 66792
|