[cfe-dev] CFG temporary objects destructors

[Marcin Świderski]

W dniu 21 października 2010 06:36 użytkownik Ted Kremenek <
kremenek at apple.com> napisał:

>
> On Oct 20, 2010, at 9:29 PM, Ted Kremenek wrote:
>
> >
> > On Oct 17, 2010, at 3:06 PM, Marcin Świderski wrote:
> >
> >> I'm currently working on modeling destructors of temporary objects in
> CFG. I've attached patch with prototype implementation and some tests.
> >>
> >
> > Hi Marcin,
> >
> > Aside from your other comment (which I will get to later), I had a
> question about the following:
> >
> > +CFGBlock
> *CFGBuilder::VisitBinaryOperatorForTemporaryDtors(BinaryOperator *E) {
> > +  if (E->isLogicalOp()) {
> > +    // Destructors for temporaries in LHS expression should be called
> after
> > +    // those for RHS expression. Even if this will unnecessarily create
> a block,
> > +    // this block will be used at least by the full expression.
> >
> > In the CFG, where we must represent control-flow between the LHS and RHS
> subexpressions, we actually have the RHS appear first in the CFG.  I
> believe, however, that the compiler chooses the reverse direction.  Should
> we reverse it to match?  I think your logic here assumes that the LHS
> temporaries are created first.
> >
> > Ted
>
> More specifically, my comment applies to the following code:
>
> +CFGBlock *CFGBuilder::VisitBinaryOperatorForTemporaryDtors(BinaryOperator
> *E) {
> +  if (E->isLogicalOp()) {
> +    // Destructors for temporaries in LHS expression should be called
> after
> +    // those for RHS expression. Even if this will unnecessarily create a
> block,
> +    // this block will be used at least by the full expression.
>
> Basically this assumption doesn't match how we treat binary operators in
> the CFG.  We should probably fix having the LHS always precessed first.  Any
> objections?


C++ standard states that at the end of full expressions temporary objects
created should be destroyed in reverse order of the completion of their
construction. So when generating destructors we want to process LHS and RHS
subexpressions in reverse order of processing them in VisitBinaryOperator.
For logical operators order is defined, and for other operators it is
undefined (I would have to check if for assignment operator it is undefined
as well...). So for logical operators everything should be left as it is
IMO, but for other operators we should probably match the compiler.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20101021/033095ce/attachment.html>