operands can't both be fully folded at the same time. For example,
in the included testcase, a global variable is being added with
an add of two values. The global variable wants RIP-relative
addressing, so it can't share the address with another base
register, but it's still possible to fold the initial add.
llvm-svn: 66865
defaults to off. When enabled, it emits range info along
with the file/line/col information for a diagnostic. This
allows tools that textually parse the output of clang to know
where the ranges are, even if they span multiple lines. For
example, with:
$ clang exprs.c -fprint-source-range-info
We now produce:
exprs.c:21:11:{21:12-21:13}: warning: use of unary operator that may be intended as compound assignment (+=)
var =+ 5; // expected-warning {{use of unary operator that may be intended as compound assignment (+=)}}
^~
exprs.c:22:11:{22:12-22:13}: warning: use of unary operator that may be intended as compound assignment (-=)
var =- 5; // expected-warning {{use of unary operator that may be intended as compound assignment (-=)}}
^~
exprs.c:36:13:{36:3-36:12}: error: assignment to cast is illegal, lvalue casts are not supported
(float*)X = P; // expected-error {{assignment to cast is illegal, lvalue casts are not supported}}
~~~~~~~~~ ^
exprs.c:41:4:{41:3-41:4}: error: called object type 'int' is not a function or function pointer
X(); // expected-error {{called object type 'int' is not a function or function pointer}}
~^
exprs.c:45:15:{45:8-45:14}{45:17-45:24}: error: invalid operands to binary expression ('int *' and '_Complex float')
P = (P-42) + Gamma*4; // expected-error {{invalid operands to binary expression ('int *' and '_Complex float')}}
~~~~~~ ^ ~~~~~~~
exprs.c:61:7:{61:16-61:22}: error: invalid application of '__alignof' to bitfield
R = __alignof(P->x); // expected-error {{invalid application of '__alignof' to bitfield}} expected-warning {{extension used}}
^ ~~~~~~
Note the range info after the column in the initial diagnostic.
This is obviously really annoying if you're not a tool parsing the
output of clang, which is why it is off by default.
llvm-svn: 66862
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
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
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
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
- 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
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
Bill Wendling