multiple basic blocks (which can happen when they contain '&&', '||', '?'). The
bug was that the loop backedge when to the last block in the loop condition, not
the first.
llvm-svn: 47649
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).
llvm-svn: 47088
"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.
llvm-svn: 47087
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.
llvm-svn: 46580
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).
llvm-svn: 46380
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.
llvm-svn: 46143
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.
llvm-svn: 45288
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
llvm-svn: 44822
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!
llvm-svn: 44327
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.
llvm-svn: 44220
Now CFG construction transparently supports Variable Length Array declarations
with expressions for their sizes, and typedefs that include VLAs.
llvm-svn: 43520
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.
llvm-svn: 42495
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.
llvm-svn: 42489
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.
llvm-svn: 42370
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.
llvm-svn: 42031
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.
llvm-svn: 41868
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.
llvm-svn: 41866
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).
llvm-svn: 41651
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
llvm-svn: 41622
Ted Kremenek