[cfe-dev] Fwd: CFGElement changes and initializers addition (with patch)

[Marcin Świderski]

Sorry, I still forget to choose "Replay all" option.

W dniu 19 sierpnia 2010 22:00 użytkownik Jordy Rose
<jediknil at belkadan.com>napisał:


> On Wed, 18 Aug 2010 09:11:29 +0200, Marcin Świderski
> <marcin.sfider at gmail.com> wrote:
> > W dniu 18 sierpnia 2010 07:47 użytkownik Jordy Rose
> > <jediknil at belkadan.com>napisał:
> >> - I like the single enum rather than kind and subkind, but there are 7
> >> elements, not 6. So it won't fit in a PointerIntPair anyway, though
> >> having
> >> a Stmt* field (or void*) and an enum field would be preferable to two
> >> PointerIntPairs.
> >> I'm still not totally convinced we need scope markers in the CFG,
> though.
> >>
> > For both destructor kinds I will need space for two pointers. For
> > automatic
> > object I need it's declaration and statement that cause destructor to be
> > called. For temporary object I need expression bound to the temporary
> and
> > the full expression that contains the temporary.
>
> Hm. This might be true, but I'm not sure. I think the element's position
> in the CFG is good enough that we don't need "the statement that causes the
> destructor to be called". (Pseudo-destructors already count as statements
> so we don't have to worry about those.)
>
> The temporary one is a little more worrisome, but again you might be able
> to get away with just the expression whose value is the temporary, and
> leave out the context. We certainly need to keep track of both parts when
> /building/ the CFG, but once it's complete we should be okay.
>
> Location where the destructor was called won't be needed much I suppose.
Instead of explicitly giving this position we could provide means of
calculating it. If this would be 'kay I think that I can squeeze everything
into one PointerIntPair.

One thing that would be needed and could be questionable (I think) would be
end of scope element. This element wouldn't have start of scope element
counterpart, and it would be used only if sequance of destructors for
automatic objects would not end with block termination statement. CFG
clients would have to ignore it always as it would be of no use to them.


> >> - In UnreachableCodeChecker::getUnreachableStmt(), isn't the block
> >> guaranteed to have an initial statement for the same reason as in
> >> ReachableCode.cpp?
> >>
> > Do you mean that if block is unreachable it will start with a statement
> > and not with initializer, destructor or scope?
>
> Hm, again I forget about scope. An unreachable block certainly can't start
> with an initializer or destructor, but it could very well start a scope.
> But this means the changes in ReachableCode.cpp have to handle this case as
> well.
>
We could write code like this:

while (true) {
  std::string a;
  break;
  break;
}

>From CFGBuilder point of view each break will cause 'a' to be destroyed, so
the block with second break as terminator will start with destructor of 'a'.
As for initializers I don't see any case that would produce block with it as
first element, but I think that it could be handled just to be on the safe
side.

- Marcin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20100820/2740a48c/attachment.html>