This revision was automatically updated to reflect the committed changes.
Closed by commit rL297084: Don't assume cleanup emission preserves dominance in
expr evaluation (authored by rnk).
Changed prior to commit:
https://reviews.llvm.org/D30590?vs=90743&id=90747#toc
Repository:
rL LLVM
htt
rnk updated this revision to Diff 90743.
rnk added a comment.
- comments
https://reviews.llvm.org/D30590
Files:
lib/CodeGen/CGCleanup.cpp
lib/CodeGen/CGExpr.cpp
lib/CodeGen/CGExprComplex.cpp
lib/CodeGen/CGExprScalar.cpp
lib/CodeGen/CodeGenFunction.h
test/CodeGenCXX/stmtexpr.cpp
Ind
rnk added inline comments.
Comment at: lib/CodeGen/CGExprComplex.cpp:204-206
+Scope.ensureDominatingValue(&Vals.first);
+Scope.ensureDominatingValue(&Vals.second);
+Scope.ForceCleanup();
rsmith wrote:
> I'm a little concerned about the loose connectio
rsmith accepted this revision.
rsmith added a comment.
This revision is now accepted and ready to land.
Hal and I discussed exactly the same problem (in the context of coroutines) on
Saturday and came up with exactly the same approach :) I think this is the
right direction.
C
rnk created this revision.
Because of the existence branches out of GNU statement expressions, it
is possible that emitting cleanups for a full expression may cause the
new insertion point to not be dominated by the result of the inner
expression. Consider this example:
struct Foo { Foo(); ~Foo
