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?
thanks
Iain

Reply via email to