[LLVMbugs] [Bug 10805] Control flow graph has possibly incorrect statements with missing source location.

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=10805

Ted Kremenek <kremenek at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |kremenek at apple.com
         Resolution|                            |INVALID

--- Comment #1 from Ted Kremenek <kremenek at apple.com> 2011-08-29 18:25:12 CDT ---
I think you are possibly misinterpreting the format of CFGs.  CFGs are not
always linearized (although they can be built that way).  By default, the CFG
does not contain a complete linearization of all subexpressions, as the
control-dependency between subexpressions and parent expressions is implied.

As for the "first" statement, are you talking about the "do"?  That appears as
a terminator in the basic block.

Also, SourceLocations are a property of the AST, not of the CFG.

FWIW, the completely linearized CFG (that the static analyzer sees) is:


 [ B4 (ENTRY) ]
    Predecessors (0):
    Successors (1): B2

 [ B1 ]
      1: this
      2: [B1.1]->done
      3: [B1.2]()
      4: ![B1.3]
      T: do ... while [B1.4]
    Predecessors (1): B2
    Successors (2): B3 B0

 [ B2 ]
      1: this
      2: [B2.1]->f
      3: operator++
      4: [B2.3]
      5: ++ [B2.2] (OperatorCall)
    Predecessors (2): B3 B4
    Successors (1): B1

 [ B3 ]
    Predecessors (1): B1
    Successors (1): B2

 [ B0 (EXIT) ]
    Predecessors (1): B1
    Successors (0):


This is correct.  Notice that the 'do... while' appears as a terminator.

The default, non-linearized CFG looks as follows:

 [ B4 (ENTRY) ]
    Predecessors (0):
    Successors (1): B2

 [ B1 ]
      1: this->done()
      2: ![B1.1]
      T: do ... while [B1.2]
    Predecessors (1): B2
    Successors (2): B3 B0

 [ B2 ]
      1: ++ this->f (OperatorCall)
    Predecessors (2): B3 B4
    Successors (1): B1

 [ B3 ]
    Predecessors (1): B1
    Successors (1): B2

 [ B0 (EXIT) ]
    Predecessors (1): B1
    Successors (0):

This is also correct.  The reason is that the load to 'f' is a subexpression,
and it implicitly has a control-dependency between that and the call to
operator++().

For consistency, we can require that the entire CFG be linearized *all the
time*, but we would need to measure the performance implication of that.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.