Re: [PING PATCH coroutines] Do not strip cleanup_point when promote temporaries out of current stmt
On 4/7/20 11:44 AM, Iain Sandoe wrote: Bin.Cheng wrote: On Mon, Mar 16, 2020 at 5:34 PM Bin.Cheng wrote: On Wed, Mar 11, 2020 at 5:07 PM Iain Sandoe wrote: Bin.Cheng wrote: On Thu, Mar 5, 2020 at 10:18 PM Iain Sandoe wrote: If it helps, I could push a branch to users/iains/ on the FSF git server with this sequence. Sorry for being slow replying. This is weird, were you testing against trunk? 1/ @Jun Ma - I think your observation is correct, we should enusre that cleanups are applied where needed to any temps that remain after we’ve those captured by reference. However, I would prefer that we do this as required, rather than assuming it will be needed so I have an updated patch below. 2/ @ Bin / Jun Ma - The problem is that the testcase seems to be fragile, perhaps it was a c-reduced one? So… I do not propose to add this test-case at this point (perhaps we could construct one that actually tests the required behaviour - that cleanups are still run correctly for temps that are not promoted by capture)? Anyway to avoid further delay, I think we should apply the patch below (I have other fixes on top of this for open PRs) OK for master? thanks Iain coroutines: Add cleanups, where required, to statements with captured references. When we promote captured temporaries to local variables, we also remove their initializers from the relevant call expression. This means that we should recompute the need for a cleanup expression once the set of temporaries that remains becomes known. gcc/cp/ChangeLog: 2020-04-07 Iain Sandoe Jun Ma * coroutines.cc (maybe_promote_captured_temps): Add a cleanup expression, if needed, to any call from which we promoted temporaries captured by reference. diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc index 983fa650b55..936be06c336 100644 --- a/gcc/cp/coroutines.cc +++ b/gcc/cp/coroutines.cc @@ -2798,11 +2798,13 @@ maybe_promote_captured_temps (tree *stmt, void *d) location_t sloc = EXPR_LOCATION (*stmt); tree aw_bind = build3_loc (sloc, BIND_EXPR, void_type_node, NULL, NULL, NULL); - tree aw_statement_current; - if (TREE_CODE (*stmt) == CLEANUP_POINT_EXPR) - aw_statement_current = TREE_OPERAND (*stmt, 0); - else - aw_statement_current = *stmt; + + /* Any cleanup point expression might no longer be necessary, since we +are removing one or more temporaries. */ + tree aw_statement_current = *stmt; + if (TREE_CODE (aw_statement_current) == CLEANUP_POINT_EXPR) + aw_statement_current = TREE_OPERAND (aw_statement_current, 0); + /* Collected the scope vars we need move the temps to regular. */ tree aw_bind_body = push_stmt_list (); tree varlist = NULL_TREE; @@ -2843,8 +2845,12 @@ maybe_promote_captured_temps (tree *stmt, void *d) /* Replace all instances of that temp in the original expr. */ cp_walk_tree (_statement_current, replace_proxy, , NULL); } - /* What's left should be the original statement with any temporaries -broken out. */ + + /* What's left should be the original statement with any co_await +captured temporaries broken out. Other temporaries might remain +so see if we need to wrap the revised statement in a cleanup. */ + aw_statement_current = + maybe_cleanup_point_expr_void (aw_statement_current); add_stmt (aw_statement_current); BIND_EXPR_BODY (aw_bind) = pop_stmt_list (aw_bind_body); awpts->captured_temps.empty (); ok -- Nathan Sidwell
Re: [PING PATCH coroutines] Do not strip cleanup_point when promote temporaries out of current stmt
On Tue, Apr 7, 2020 at 11:45 PM Iain Sandoe wrote: > > Bin.Cheng wrote: > > > On Mon, Mar 16, 2020 at 5:34 PM Bin.Cheng wrote: > >> On Wed, Mar 11, 2020 at 5:07 PM Iain Sandoe wrote: > >>> Bin.Cheng wrote: > >>> > On Thu, Mar 5, 2020 at 10:18 PM Iain Sandoe wrote: > > >>> If it helps, I could push a branch to users/iains/ on the FSF git server > >>> with this sequence. > >> Sorry for being slow replying. This is weird, were you testing against > >> trunk? > > 1/ @Jun Ma > > - I think your observation is correct, we should enusre that cleanups are > applied where needed >to any temps that remain after we’ve those captured by reference. > > However, I would prefer that we do this as required, rather than assuming > it will be needed so > I have an updated patch below. Sorry it's been quite long, I don't remember the detail of this change. Since this new version fixes the ICE too, please go ahead commit it. > > 2/ @ Bin / Jun Ma > > - The problem is that the testcase seems to be fragile, perhaps it was a > c-reduced one? It's strange, however, I don't see being c-reduced has impact here in this scenario. > > So… I do not propose to add this test-case at this point (perhaps we could > construct one that actually > tests the required behaviour - that cleanups are still run correctly for > temps that are not promoted by > capture)? > > Anyway to avoid further delay, I think we should apply the patch below (I > have other fixes on top of this > for open PRs) > > OK for master? Yes, please. Also one of approved patch is waiting for this one. Thanks, bin > thanks > Iain > > coroutines: Add cleanups, where required, to statements with captured > references. > > When we promote captured temporaries to local variables, we also > remove their initializers from the relevant call expression. This > means that we should recompute the need for a cleanup expression > once the set of temporaries that remains becomes known. > > gcc/cp/ChangeLog: > > 2020-04-07 Iain Sandoe > Jun Ma > > * coroutines.cc (maybe_promote_captured_temps): Add a > cleanup expression, if needed, to any call from which > we promoted temporaries captured by reference. > > diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc > index 983fa650b55..936be06c336 100644 > --- a/gcc/cp/coroutines.cc > +++ b/gcc/cp/coroutines.cc > @@ -2798,11 +2798,13 @@ maybe_promote_captured_temps (tree *stmt, void *d) >location_t sloc = EXPR_LOCATION (*stmt); >tree aw_bind > = build3_loc (sloc, BIND_EXPR, void_type_node, NULL, NULL, NULL); > - tree aw_statement_current; > - if (TREE_CODE (*stmt) == CLEANUP_POINT_EXPR) > - aw_statement_current = TREE_OPERAND (*stmt, 0); > - else > - aw_statement_current = *stmt; > + > + /* Any cleanup point expression might no longer be necessary, since we > +are removing one or more temporaries. */ > + tree aw_statement_current = *stmt; > + if (TREE_CODE (aw_statement_current) == CLEANUP_POINT_EXPR) > + aw_statement_current = TREE_OPERAND (aw_statement_current, 0); > + >/* Collected the scope vars we need move the temps to regular. */ >tree aw_bind_body = push_stmt_list (); >tree varlist = NULL_TREE; > @@ -2843,8 +2845,12 @@ maybe_promote_captured_temps (tree *stmt, void *d) > /* Replace all instances of that temp in the original expr. */ > cp_walk_tree (_statement_current, replace_proxy, , NULL); > } > - /* What's left should be the original statement with any temporaries > -broken out. */ > + > + /* What's left should be the original statement with any co_await > +captured temporaries broken out. Other temporaries might remain > +so see if we need to wrap the revised statement in a cleanup. */ > + aw_statement_current = > + maybe_cleanup_point_expr_void (aw_statement_current); >add_stmt (aw_statement_current); >BIND_EXPR_BODY (aw_bind) = pop_stmt_list (aw_bind_body); >awpts->captured_temps.empty (); >
Re: [PING PATCH coroutines] Do not strip cleanup_point when promote temporaries out of current stmt
Bin.Cheng wrote: > On Mon, Mar 16, 2020 at 5:34 PM Bin.Cheng wrote: >> On Wed, Mar 11, 2020 at 5:07 PM Iain Sandoe wrote: >>> Bin.Cheng wrote: >>> On Thu, Mar 5, 2020 at 10:18 PM Iain Sandoe wrote: >>> If it helps, I could push a branch to users/iains/ on the FSF git server >>> with this sequence. >> Sorry for being slow replying. This is weird, were you testing against >> trunk? 1/ @Jun Ma - I think your observation is correct, we should enusre that cleanups are applied where needed to any temps that remain after we’ve those captured by reference. However, I would prefer that we do this as required, rather than assuming it will be needed so I have an updated patch below. 2/ @ Bin / Jun Ma - The problem is that the testcase seems to be fragile, perhaps it was a c-reduced one? So… I do not propose to add this test-case at this point (perhaps we could construct one that actually tests the required behaviour - that cleanups are still run correctly for temps that are not promoted by capture)? Anyway to avoid further delay, I think we should apply the patch below (I have other fixes on top of this for open PRs) OK for master? thanks Iain coroutines: Add cleanups, where required, to statements with captured references. When we promote captured temporaries to local variables, we also remove their initializers from the relevant call expression. This means that we should recompute the need for a cleanup expression once the set of temporaries that remains becomes known. gcc/cp/ChangeLog: 2020-04-07 Iain Sandoe Jun Ma * coroutines.cc (maybe_promote_captured_temps): Add a cleanup expression, if needed, to any call from which we promoted temporaries captured by reference. diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc index 983fa650b55..936be06c336 100644 --- a/gcc/cp/coroutines.cc +++ b/gcc/cp/coroutines.cc @@ -2798,11 +2798,13 @@ maybe_promote_captured_temps (tree *stmt, void *d) location_t sloc = EXPR_LOCATION (*stmt); tree aw_bind = build3_loc (sloc, BIND_EXPR, void_type_node, NULL, NULL, NULL); - tree aw_statement_current; - if (TREE_CODE (*stmt) == CLEANUP_POINT_EXPR) - aw_statement_current = TREE_OPERAND (*stmt, 0); - else - aw_statement_current = *stmt; + + /* Any cleanup point expression might no longer be necessary, since we +are removing one or more temporaries. */ + tree aw_statement_current = *stmt; + if (TREE_CODE (aw_statement_current) == CLEANUP_POINT_EXPR) + aw_statement_current = TREE_OPERAND (aw_statement_current, 0); + /* Collected the scope vars we need move the temps to regular. */ tree aw_bind_body = push_stmt_list (); tree varlist = NULL_TREE; @@ -2843,8 +2845,12 @@ maybe_promote_captured_temps (tree *stmt, void *d) /* Replace all instances of that temp in the original expr. */ cp_walk_tree (_statement_current, replace_proxy, , NULL); } - /* What's left should be the original statement with any temporaries -broken out. */ + + /* What's left should be the original statement with any co_await +captured temporaries broken out. Other temporaries might remain +so see if we need to wrap the revised statement in a cleanup. */ + aw_statement_current = + maybe_cleanup_point_expr_void (aw_statement_current); add_stmt (aw_statement_current); BIND_EXPR_BODY (aw_bind) = pop_stmt_list (aw_bind_body); awpts->captured_temps.empty ();
Re: [PING PATCH coroutines] Do not strip cleanup_point when promote temporaries out of current stmt
Hi Bin, Bin.Cheng via Gcc-patches wrote: On Mon, Mar 16, 2020 at 5:34 PM Bin.Cheng wrote: On Wed, Mar 11, 2020 at 5:07 PM Iain Sandoe wrote: Bin.Cheng wrote: On Thu, Mar 5, 2020 at 10:18 PM Iain Sandoe wrote: With current trunk + Bin’s two approved patches. I see no change in the testcase (lambda-09-capture-object.C) before / after the patch (it fails for me at -O0 only - in both cases). If it helps, I could push a branch to users/iains/ on the FSF git server with this sequence. Sorry for being slow replying. This is weird, were you testing against trunk? Yes. So I suspect you were testing with local changes? No local changes. (and two different platforms - x86_64-darwin16, and x86_64-linux-gnu [cfarm122]). * At least on Darwin (I have a trunk build from overnight) I see no change at r10-7390-g27f8c8c4c923. If so, please push the branch. Ping. Any updates? * I am currently working first on trying to complete the n4849 update changes. * This remains on my TODO. - I am trying to figure out how you can consistently get different results from me. I noticed you committed fix to coro-torture.exp, Hopefully, at least, the testsuite problem is fixed for you now? thanks Iain
Re: [PING PATCH coroutines] Do not strip cleanup_point when promote temporaries out of current stmt
On Mon, Mar 16, 2020 at 5:34 PM Bin.Cheng wrote: > > On Wed, Mar 11, 2020 at 5:07 PM Iain Sandoe wrote: > > > > Bin.Cheng wrote: > > > > > On Thu, Mar 5, 2020 at 10:18 PM Iain Sandoe wrote: > > > > >> With current trunk + Bin’s two approved patches. > > >> > > >> I see no change in the testcase (lambda-09-capture-object.C) before / > > >> after > > >> the patch > > >> (it fails for me at -O0 only - in both cases). > > > > > > > > I tried exactly what you did, however, the result is different. > > > > I am a bit concerned that we get different results - yesterday I retested > > this on: > > Linux : x86_64-linux (cfarm gcc122) > > Darwin (x86_64-darwin16), > > with the same results on both platforms. > > > > 1) I applied the two testcases (note I have renamed > > lambda-09-capture-object.C => lambda-11-capture-object.C so that the test > > numbers are sequential). However, I have not changed the test in any other > > way. > > > > Native configuration is x86_64-pc-linux-gnu > > > > === g++ tests === > > > > Schedule of variations: > > unix/-m32 > > unix/-m64 > > > > Running target unix/-m32 > > Using /usr/share/dejagnu/baseboards/unix.exp as board description file for > > target. > > Using /usr/share/dejagnu/config/unix.exp as generic interface file for > > target. > > Using /home/iains/gcc-master/src-patched/gcc/testsuite/config/default.exp > > as tool-and-target-specific interface file. > > Running > > /home/iains/gcc-master/src-patched/gcc/testsuite/g++.dg/coroutines/coroutines.exp > > ... > > FAIL: g++.dg/coroutines/co-await-syntax-10.C (internal compiler error) > > FAIL: g++.dg/coroutines/co-await-syntax-10.C (test for excess errors) > > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C (internal > > compiler error) > > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C (test for excess > > errors) > > Running > > /home/iains/gcc-master/src-patched/gcc/testsuite/g++.dg/coroutines/torture/coro-torture.exp > > ... > > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C -O0 (internal > > compiler error) > > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C -O0 (test for > > excess errors) > > > > Running target unix/-m64 > > Using /usr/share/dejagnu/baseboards/unix.exp as board description file for > > target. > > Using /usr/share/dejagnu/config/unix.exp as generic interface file for > > target. > > Using /home/iains/gcc-master/src-patched/gcc/testsuite/config/default.exp > > as tool-and-target-specific interface file. > > Running > > /home/iains/gcc-master/src-patched/gcc/testsuite/g++.dg/coroutines/coroutines.exp > > ... > > FAIL: g++.dg/coroutines/co-await-syntax-10.C (internal compiler error) > > FAIL: g++.dg/coroutines/co-await-syntax-10.C (test for excess errors) > > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C (internal > > compiler error) > > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C (test for excess > > errors) > > Running > > /home/iains/gcc-master/src-patched/gcc/testsuite/g++.dg/coroutines/torture/coro-torture.exp > > ... > > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C -O0 (internal > > compiler error) > > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C -O0 (test for > > excess errors) > > > > ^^ so, this shows that both tests fail (co-await-syntax-10.C is expected) > > > > 2) I apply Bin’s patch (Pickup more CO_AWAIT_EXPR expanding cases) (which > > is approved) > > > > Native configuration is x86_64-pc-linux-gnu > > > > === g++ tests === > > > > Schedule of variations: > > unix/-m32 > > unix/-m64 > > > > Running target unix/-m32 > > Using /usr/share/dejagnu/baseboards/unix.exp as board description file for > > target. > > Using /usr/share/dejagnu/config/unix.exp as generic interface file for > > target. > > Using /home/iains/gcc-master/src-patched/gcc/testsuite/config/default.exp > > as tool-and-target-specific interface file. > > Running > > /home/iains/gcc-master/src-patched/gcc/testsuite/g++.dg/coroutines/coroutines.exp > > ... > > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C (internal > > compiler error) > > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C (test for excess > > errors) > > Running > > /home/iains/gcc-master/src-patched/gcc/testsuite/g++.dg/coroutines/torture/coro-torture.exp > > ... > > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C -O0 (internal > > compiler error) > > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C -O0 (test for > > excess errors) > > > > Running target unix/-m64 > > Using /usr/share/dejagnu/baseboards/unix.exp as board description file for > > target. > > Using /usr/share/dejagnu/config/unix.exp as generic interface file for > > target. > > Using /home/iains/gcc-master/src-patched/gcc/testsuite/config/default.exp > > as tool-and-target-specific interface file. > > Running > >
Re: [PING PATCH coroutines] Do not strip cleanup_point when promote temporaries out of current stmt
On Wed, Mar 11, 2020 at 5:07 PM Iain Sandoe wrote: > > Bin.Cheng wrote: > > > On Thu, Mar 5, 2020 at 10:18 PM Iain Sandoe wrote: > > >> With current trunk + Bin’s two approved patches. > >> > >> I see no change in the testcase (lambda-09-capture-object.C) before / after > >> the patch > >> (it fails for me at -O0 only - in both cases). > > > > > I tried exactly what you did, however, the result is different. > > I am a bit concerned that we get different results - yesterday I retested > this on: > Linux : x86_64-linux (cfarm gcc122) > Darwin (x86_64-darwin16), > with the same results on both platforms. > > 1) I applied the two testcases (note I have renamed > lambda-09-capture-object.C => lambda-11-capture-object.C so that the test > numbers are sequential). However, I have not changed the test in any other > way. > > Native configuration is x86_64-pc-linux-gnu > > === g++ tests === > > Schedule of variations: > unix/-m32 > unix/-m64 > > Running target unix/-m32 > Using /usr/share/dejagnu/baseboards/unix.exp as board description file for > target. > Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. > Using /home/iains/gcc-master/src-patched/gcc/testsuite/config/default.exp as > tool-and-target-specific interface file. > Running > /home/iains/gcc-master/src-patched/gcc/testsuite/g++.dg/coroutines/coroutines.exp > ... > FAIL: g++.dg/coroutines/co-await-syntax-10.C (internal compiler error) > FAIL: g++.dg/coroutines/co-await-syntax-10.C (test for excess errors) > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C (internal compiler > error) > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C (test for excess > errors) > Running > /home/iains/gcc-master/src-patched/gcc/testsuite/g++.dg/coroutines/torture/coro-torture.exp > ... > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C -O0 (internal > compiler error) > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C -O0 (test for > excess errors) > > Running target unix/-m64 > Using /usr/share/dejagnu/baseboards/unix.exp as board description file for > target. > Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. > Using /home/iains/gcc-master/src-patched/gcc/testsuite/config/default.exp as > tool-and-target-specific interface file. > Running > /home/iains/gcc-master/src-patched/gcc/testsuite/g++.dg/coroutines/coroutines.exp > ... > FAIL: g++.dg/coroutines/co-await-syntax-10.C (internal compiler error) > FAIL: g++.dg/coroutines/co-await-syntax-10.C (test for excess errors) > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C (internal compiler > error) > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C (test for excess > errors) > Running > /home/iains/gcc-master/src-patched/gcc/testsuite/g++.dg/coroutines/torture/coro-torture.exp > ... > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C -O0 (internal > compiler error) > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C -O0 (test for > excess errors) > > ^^ so, this shows that both tests fail (co-await-syntax-10.C is expected) > > 2) I apply Bin’s patch (Pickup more CO_AWAIT_EXPR expanding cases) (which is > approved) > > Native configuration is x86_64-pc-linux-gnu > > === g++ tests === > > Schedule of variations: > unix/-m32 > unix/-m64 > > Running target unix/-m32 > Using /usr/share/dejagnu/baseboards/unix.exp as board description file for > target. > Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. > Using /home/iains/gcc-master/src-patched/gcc/testsuite/config/default.exp as > tool-and-target-specific interface file. > Running > /home/iains/gcc-master/src-patched/gcc/testsuite/g++.dg/coroutines/coroutines.exp > ... > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C (internal compiler > error) > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C (test for excess > errors) > Running > /home/iains/gcc-master/src-patched/gcc/testsuite/g++.dg/coroutines/torture/coro-torture.exp > ... > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C -O0 (internal > compiler error) > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C -O0 (test for > excess errors) > > Running target unix/-m64 > Using /usr/share/dejagnu/baseboards/unix.exp as board description file for > target. > Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. > Using /home/iains/gcc-master/src-patched/gcc/testsuite/config/default.exp as > tool-and-target-specific interface file. > Running > /home/iains/gcc-master/src-patched/gcc/testsuite/g++.dg/coroutines/coroutines.exp > ... > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C (internal compiler > error) > FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C (test for excess > errors) > Running >
Re: [PING PATCH coroutines] Do not strip cleanup_point when promote temporaries out of current stmt
Bin.Cheng wrote: > On Thu, Mar 5, 2020 at 10:18 PM Iain Sandoe wrote: >> With current trunk + Bin’s two approved patches. >> >> I see no change in the testcase (lambda-09-capture-object.C) before / after >> the patch >> (it fails for me at -O0 only - in both cases). > > I tried exactly what you did, however, the result is different. I am a bit concerned that we get different results - yesterday I retested this on: Linux : x86_64-linux (cfarm gcc122) Darwin (x86_64-darwin16), with the same results on both platforms. 1) I applied the two testcases (note I have renamed lambda-09-capture-object.C => lambda-11-capture-object.C so that the test numbers are sequential). However, I have not changed the test in any other way. Native configuration is x86_64-pc-linux-gnu === g++ tests === Schedule of variations: unix/-m32 unix/-m64 Running target unix/-m32 Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /home/iains/gcc-master/src-patched/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /home/iains/gcc-master/src-patched/gcc/testsuite/g++.dg/coroutines/coroutines.exp ... FAIL: g++.dg/coroutines/co-await-syntax-10.C (internal compiler error) FAIL: g++.dg/coroutines/co-await-syntax-10.C (test for excess errors) FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C (internal compiler error) FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C (test for excess errors) Running /home/iains/gcc-master/src-patched/gcc/testsuite/g++.dg/coroutines/torture/coro-torture.exp ... FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C -O0 (internal compiler error) FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C -O0 (test for excess errors) Running target unix/-m64 Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /home/iains/gcc-master/src-patched/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /home/iains/gcc-master/src-patched/gcc/testsuite/g++.dg/coroutines/coroutines.exp ... FAIL: g++.dg/coroutines/co-await-syntax-10.C (internal compiler error) FAIL: g++.dg/coroutines/co-await-syntax-10.C (test for excess errors) FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C (internal compiler error) FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C (test for excess errors) Running /home/iains/gcc-master/src-patched/gcc/testsuite/g++.dg/coroutines/torture/coro-torture.exp ... FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C -O0 (internal compiler error) FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C -O0 (test for excess errors) ^^ so, this shows that both tests fail (co-await-syntax-10.C is expected) 2) I apply Bin’s patch (Pickup more CO_AWAIT_EXPR expanding cases) (which is approved) Native configuration is x86_64-pc-linux-gnu === g++ tests === Schedule of variations: unix/-m32 unix/-m64 Running target unix/-m32 Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /home/iains/gcc-master/src-patched/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /home/iains/gcc-master/src-patched/gcc/testsuite/g++.dg/coroutines/coroutines.exp ... FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C (internal compiler error) FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C (test for excess errors) Running /home/iains/gcc-master/src-patched/gcc/testsuite/g++.dg/coroutines/torture/coro-torture.exp ... FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C -O0 (internal compiler error) FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C -O0 (test for excess errors) Running target unix/-m64 Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /home/iains/gcc-master/src-patched/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /home/iains/gcc-master/src-patched/gcc/testsuite/g++.dg/coroutines/coroutines.exp ... FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C (internal compiler error) FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C (test for excess errors) Running /home/iains/gcc-master/src-patched/gcc/testsuite/g++.dg/coroutines/torture/coro-torture.exp ... FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C -O0 (internal compiler error) FAIL: g++.dg/coroutines/torture/lambda-11-capture-object.C -O0 (test for excess errors) ^^^ this shows that co-await-syntax-10.C is now OK (which is why I was
Re: [PING PATCH coroutines] Do not strip cleanup_point when promote temporaries out of current stmt
On Thu, Mar 5, 2020 at 10:18 PM Iain Sandoe wrote: > > Hello JunMa, > > JunMa wrote: > > > Ping > > Once again, sorry for taking time to review this. > > > 在 2020/2/27 上午10:18, JunMa 写道: > >> 在 2020/2/11 上午10:14, JunMa 写道: > >> Kindly ping > >> > >> Regards > >> JunMa > >>> Hi > >>> In maybe_promote_captured_temps, the cleanup_point_stmt has been > >>> stripped when handle temporaries captured by reference. However, maybe > >>> there are non-reference temporaries in current stmt which cause ice in > >>> gimpilify pass. > >>> > >>> This patch fix this. The testcase comes from cppcoro and is reduced by > >>> creduce. > > With current trunk + Bin’s two approved patches. > > I see no change in the testcase (lambda-09-capture-object.C) before / after > the patch > (it fails for me at -O0 only - in both cases). Hi Iain, I tried exactly what you did, however, the result is different. With current trunk(cb2c60206f4f2218f84ccde21663b00de068d8c7) with my approved patch, the case(lambda-09-capture-object.C) still causes ICE. Actually, the same ICE happens in testcase(co-await-syntax-11.C) added by my patch. So this one is a prerequisite for my approved patch. Thanks, bin > > please could you check? > thanks > Iain >
Re: [PING PATCH coroutines] Do not strip cleanup_point when promote temporaries out of current stmt
在 2020/3/5 下午10:18, Iain Sandoe 写道: Hello JunMa, JunMa wrote: Ping Once again, sorry for taking time to review this. 在 2020/2/27 上午10:18, JunMa 写道: 在 2020/2/11 上午10:14, JunMa 写道: Kindly ping Regards JunMa Hi In maybe_promote_captured_temps, the cleanup_point_stmt has been stripped when handle temporaries captured by reference. However, maybe there are non-reference temporaries in current stmt which cause ice in gimpilify pass. This patch fix this. The testcase comes from cppcoro and is reduced by creduce. With current trunk + Bin’s two approved patches. I see no change in the testcase (lambda-09-capture-object.C) before / after the patch (it fails for me at -O0 only - in both cases). please could you check? As I said at previous mail, this patch fix the ICE in gimpilify pass. I test with current trunk + Bin's two patches, the testcase passes with the patch and fails without the patch. It also fix co-await-syntax-11.C which caused by same ICE. could you do double check? Regards JunMa thanks Iain
Re: [PING PATCH coroutines] Do not strip cleanup_point when promote temporaries out of current stmt
Hello JunMa, JunMa wrote: Ping Once again, sorry for taking time to review this. 在 2020/2/27 上午10:18, JunMa 写道: 在 2020/2/11 上午10:14, JunMa 写道: Kindly ping Regards JunMa Hi In maybe_promote_captured_temps, the cleanup_point_stmt has been stripped when handle temporaries captured by reference. However, maybe there are non-reference temporaries in current stmt which cause ice in gimpilify pass. This patch fix this. The testcase comes from cppcoro and is reduced by creduce. With current trunk + Bin’s two approved patches. I see no change in the testcase (lambda-09-capture-object.C) before / after the patch (it fails for me at -O0 only - in both cases). please could you check? thanks Iain
Re: [PING PATCH coroutines] Do not strip cleanup_point when promote temporaries out of current stmt
Ping Regards JunMa 在 2020/2/27 上午10:18, JunMa 写道: 在 2020/2/11 上午10:14, JunMa 写道: Kindly ping Regards JunMa Hi In maybe_promote_captured_temps, the cleanup_point_stmt has been stripped when handle temporaries captured by reference. However, maybe there are non-reference temporaries in current stmt which cause ice in gimpilify pass. This patch fix this. The testcase comes from cppcoro and is reduced by creduce. Bootstrap and test on X86_64, is it OK? Regards JunMa gcc/cp 2020-02-11 Jun Ma * coroutines.cc (maybe_promote_captured_temps): Do not strip cleanup_point_stmt. gcc/testsuite 2020-02-11 Jun Ma * g++.dg/coroutines/torture/lambda-09-capture-object.C: New test.
Re: [PING PATCH coroutines] Do not strip cleanup_point when promote temporaries out of current stmt
在 2020/2/11 上午10:14, JunMa 写道: Kindly ping Regards JunMa Hi In maybe_promote_captured_temps, the cleanup_point_stmt has been stripped when handle temporaries captured by reference. However, maybe there are non-reference temporaries in current stmt which cause ice in gimpilify pass. This patch fix this. The testcase comes from cppcoro and is reduced by creduce. Bootstrap and test on X86_64, is it OK? Regards JunMa gcc/cp 2020-02-11 Jun Ma * coroutines.cc (maybe_promote_captured_temps): Do not strip cleanup_point_stmt. gcc/testsuite 2020-02-11 Jun Ma * g++.dg/coroutines/torture/lambda-09-capture-object.C: New test.
