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
> 

Attachment: 0001-c-coroutines-contracts-Handle-coroutine-and-void-fun.patch
Description: Binary data

Reply via email to