branch ALWAYS be the last successor for a switch-terminated block. This allows
clients to distinguish cases like the following:
switch(...)
case XXX:
switch(...) {
case YYY: ...
}
case ZZZ: ..
}
In this case, the block with "case ZZZ:" is the default block for the inner
switch statement, but that case is associated with the outer switch statement,
and not the inner one. Clients can test for this behavior by checking if a
successor block is the last one (and thus just assume that this is the "default"
case).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@47088 91177308-0d34-0410-b5e6-96231b3b80d8
"default" case. In such cases, we now correctly add the CFGBlock representing
the code after the switch statement as a successor to the block terminated by
the switch statement.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@47087 91177308-0d34-0410-b5e6-96231b3b80d8
pretty-print a block's terminator.
When building CFGs, for IfStmts ('if'), we no longer add the ParenExpr
that is the subexpression of the IfStmt to the CFG; instead we add its
first descendant subexpression that is not a ParenExpr.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@46580 91177308-0d34-0410-b5e6-96231b3b80d8
some previously missing NULL pointer checks.
Modified the UninitializedValues analysis to not expect that every Expr* at the
block-level is a block-level expression (we probably need to change the name of
such expressions to something truer to their meaning).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@46380 91177308-0d34-0410-b5e6-96231b3b80d8
include the assignment expressions whose result (as in the value of the
expression) is used by other expressions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@46361 91177308-0d34-0410-b5e6-96231b3b80d8
is because GNU-style Statement-expressions cause the last statement in the
statement-expression to act like an expression.
We now have two notions: block-level statements and block-level expressions.
The former are all Stmt* that appear in the list of statements in CFGBlocks. The
latter is the subset of the former; these block-level statements are used as
subexpressions somewhere in the AST. CFG::isBlockExpr() returns true for the
latter, not the former (previously isBlockExpr() always returned true for
non-Expr Stmt*).
Modified the LiveVariables analysis to also track liveness state for block-level
expressions (using the updated definition of block-level expressions).
Modified the dataflow solver so that when it records values for block-level
statements, it records the dataflow value *before* the transfer function for a
Stmt* is evaluated (not after). This is more in sync in what clients will want.
Modified CFGStmtVisitor to record the current block-level statement.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@46143 91177308-0d34-0410-b5e6-96231b3b80d8
to have a much simpler, cleaner interpretation of what is a "location"
in a function (as encoded by a CFG).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@45846 91177308-0d34-0410-b5e6-96231b3b80d8
is best explained by illustration:
[ B2 ]
1: x
T: [B2.1] && ...
Predecessors (1): B4
Successors (2): B3 B1
Block "B3" should be the block where we evaluate "y" when "x" evaluates to
true. Previously we had the successor list reversed. Now this behavior matches
with how we handle other conditional branches.
Thanks to Nuno Lopes for reporting this problem.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@45288 91177308-0d34-0410-b5e6-96231b3b80d8
between fetching the size of the expression map (for use as
the next integer id for an Expr*) and the creation of the
entry in the map could be non-deterministic. This could
cause the size of the map to be incremented prior to the
index being determine.
On Linux the map entry would be created first, causing the
map to the "size" to be incremented prior to it being
queried. On Mac OS X we had the reverse behavior. Now the
size is always queried prior to the new id being inserted
into the map.
This was the real cause of the bit-overrun triggered in
PR 1847:
http://llvm.org/bugs/show_bug.cgi?id=1847
Also reverted the change in patch 44813, which was a bogus
fix to this problem:
http://llvm.org/viewvc/llvm-project?rev=44813&view=rev
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@44822 91177308-0d34-0410-b5e6-96231b3b80d8
extension "?:" for the ternary operator, e.g.: x ?: y; This expression is
represented in the clang ASTs as a ConditionalOperator whose LHS expression is
NULL. Now we handle this special case, causing the block containing the
condition to be a predecessor to the block that "merges" the values of the
ternary operator.
Thanks to Nuno Lopes for identifying and diagnosing this bug!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@44327 91177308-0d34-0410-b5e6-96231b3b80d8
the StmtIterator referring to the initializers of a chain of Decls was equal
to the "end" iterator. The particular bug manifested when an iterator was
created on a chain of decls with no initializers.
Thanks to Nuno Lopes for reporting this bug and providing a patch.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@44220 91177308-0d34-0410-b5e6-96231b3b80d8
Now CFG construction transparently supports Variable Length Array declarations
with expressions for their sizes, and typedefs that include VLAs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@43520 91177308-0d34-0410-b5e6-96231b3b80d8
expressions to IDs. This is used by various dataflow analyses, but is
also useful for anyone querying a CFG to determine where an expression
is evaluated.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@42495 91177308-0d34-0410-b5e6-96231b3b80d8
as a member function. This function is no longer needed within the CFG
class, and logically belongs to the Stmt class as a predicate for a
Stmt instance.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@42489 91177308-0d34-0410-b5e6-96231b3b80d8
BUG 1)
CFG failed to build for empty functions, or functions containing only
NullStmts or empty compound statements.
We now handle such cases, although now we cannot test for CFG
construction failure by asserting that the last block constructed is
not NULL (since it now may be).
BUG 2)
CFG construction segfaulted on some cases when walking the AST and not
taking into account that some children of a statement may be NULL.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@42370 91177308-0d34-0410-b5e6-96231b3b80d8
to serve as the entry block. An empty entry block (just as with an
empty exit block, which we already have) simplifies building analyses on top
of CFGs with very little extra overhead.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@42031 91177308-0d34-0410-b5e6-96231b3b80d8
This method is used to determine if an expression contains implicit
control-flow, and thus appears in a distinct statement slot in the CFG.
For example:
(1) x = ... ? ... ? ...
logically becomes:
(1) ... ? ... : ... (a unique statement slot for the ternary ?)
(2) x = [E1] (where E1 is actually the ConditionalOperator*)
A client of the CFG, when walking the statement at (2), will encounter
E1. In this case, hasImplicitControlFlow(E1) == true, and the client
will know that the expression E1 is explicitly placed into its own statement
slot to capture the implicit control-flow it has.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41868 91177308-0d34-0410-b5e6-96231b3b80d8
where not reversing the order of their subexpression blocks.
Added feature where CallExprs are placed in their own statement slot in
a CFGBlock. Thus we have a designated "return site" within a CFGBlock when
reasoning about function calls.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41866 91177308-0d34-0410-b5e6-96231b3b80d8
be passed as an (optional) argument to StmtPrinter to customize
printing of AST nodes.
Used new PrinterHelper interface to enhance printing and visualization
of CFGs. The CFGs now illustrate the semantic connectives between
statements and terminators, wheras in the previous printing certain
expressions would (visible) be printed multiple times to reflect which
expressions used the results of other expressions.
The end result is that the CFG is easier to read for flow of
expression values (following principles similar to the LLVM IR).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41651 91177308-0d34-0410-b5e6-96231b3b80d8
introduced by moving "CaseStmt" pointers out of the list of statements
and into the explicit "label" associated with a CFGBlock. --This
line, and those below, will be ignored--
M AST/CFG.cpp
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41622 91177308-0d34-0410-b5e6-96231b3b80d8
blocks involving only ';' statements. We now correctly handle the following:
void empty_label() { l1: ; }
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41619 91177308-0d34-0410-b5e6-96231b3b80d8
an empty then or else block (or contained only ';' statements).
For example, we now handle the following:
int empty_else() { if (0) { int a; } else ; }
int empty_then() { if (0) ; else { int a; } }
Thanks to Nico Weber for spotting this problem.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41617 91177308-0d34-0410-b5e6-96231b3b80d8
block begins with a label or case statement, CFGBlock::getLabel() will
return the corresponding LabelStmt/CaseStmt/DefaultStmt.
LabelStmts and SwitchCases no longer appear within the "executable"
statements of a CFGBlock.
More cleanups on visualization/pretty-printing of CFGs (less verbose).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41585 91177308-0d34-0410-b5e6-96231b3b80d8
(LLVM-provided) graph algorithms such as DFS and graph visualization
to work effortless on source-level CFGs.
Further cleanup on pretty printing of CFGs. CFGBlock::dump and
CFGBlock::print now take the parent CFG as an argument. This allows
CFGBlocks to print their own appropriate label indicating whether or
not they are the Entry/Exit/IndirectGotoBlock without the CFG::print
routine doing it instead.
Added Graphviz visualization for CFGs: CFG::viewCFG. This employs the
GraphTraits just implemented.
Added "-view-cfg" mode the to clang driver. This is identical to
"-dump-cfg" except that it calls Graphviz to visualize the CFGs
instead of dumping them to the terminal.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41580 91177308-0d34-0410-b5e6-96231b3b80d8
This involves the construction of a specialized "dispatch" block that
all basic blocks containing indirect gotos unconditionally transfer
control-flow to. The successors of the dispatch block has as its successors
all of the blocks containing labels whose address was taken somewhere in
the function.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41554 91177308-0d34-0410-b5e6-96231b3b80d8
Ted Kremenek
Chris Lattner
Hartmut Kaiser