HI Jason, > On 9 Jul 2024, at 22:55, Jason Merrill <ja...@redhat.com> wrote: > > On 7/9/24 11:52 AM, Iain Sandoe wrote: >> Hi Folks >>> On 8 Jul 2024, at 20:57, Jason Merrill <ja...@redhat.com> wrote: >>> >>> On 7/8/24 3:37 PM, Iain Sandoe wrote: >>>>> On 8 Jul 2024, at 20:19, Jason Merrill <ja...@redhat.com> wrote: >>>>> >>>>> On 6/17/24 8:15 AM, Iain Sandoe wrote: >>>>>> potentially_transformed_function_body (); >>>>>> } >>>>>> finally >>>>>> { >>>>>> handle_post_condition_checking (); >>>>>> } >>>>>> else [only if the function is not marked noexcept(true) ] >>>>>> { >>>>>> __rethrow (); >>>>> >>>>> This sounds undesirable, EH normally continues unwinding after running a >>>>> cleanup. Why would the exception be considered caught in a way that >>>>> needs a rethrow? >>>> We need to implement that the no-EH cleanup [i.e. the postcondition] does >>>> _not_ run when an exception is thrown. Right now there’s no HANDLER type >>>> that does that - we have EH_ONLY but no NON_EH one (otherwise I'd have >>>> built a C++ try). >>>> however, I could not figure out how to make this arm of the EH_ELSE_EXPR >>>> work as an empty construct (the gimplifier does not seem to expect this). >>> >>> You can't just put void_node in the else arm? >> I had tried a number of permutations (void_node, empty_stmt, empty statement >> list etc). Unfortunately, at present that causes the EH_ELSE expression to >> be silently dropped in gimplication. The fact that you think it should work >> (as did i) makes me think either we have a gimplifier bug or a >> misunderstanding: >> @Alex; >> we have (gcc/gimplify.cc:18423): >> if (!gimple_seq_empty_p (n) && !gimple_seq_empty_p (e)) >> { >> geh_else *stmt = gimple_build_eh_else (n, e); >> gimple_seq_add_stmt (&cleanup, stmt); >> } >> Which essentially says “if either of the sub-expressions to this are empty, >> then do not build it” >> Was there a reason for this, or is it a typo? >> If I replace ‘&&' by ‘||' (i.e. “if either of the sub-expressions is >> present, then build it” then things behave as I expect. >> IMO it the current action _is_ intended >> (a) it should at least emit a checking diagnostic >> (b) we need to figure out how to extend it so that we can implement what’s >> needed (non-EH only cleanups) >> So I patched the gimplifier as above and initial testing says that this >> change does not cause any C++ regressions - but I need to do Ada, >> Objective-C etc too. >> thoughts? > > That sounds good to me, it does seem like a typo.
Here is the revised patch - which implements the gimplifier change and thus simplifes the rest. OK for trunk? thanks Iain P.S. I did not figure out how to find the right message-id to reply to from git send-email, so attaching. > > Jason >
0001-c-coroutines-contracts-Handle-coroutine-and-void-fun.patch
Description: Binary data