On Jun 27, 2019, Richard Biener <richard.guent...@gmail.com> wrote: > On Thu, Jun 27, 2019 at 10:18 AM Alexandre Oliva <ol...@adacore.com> wrote:
>> @@ -909,6 +909,13 @@ DEFTREECODE (TRY_CATCH_EXPR, "try_catch_expr", >> tcc_statement, 2) >> The second operand is a cleanup expression which is evaluated >> on any exit (normal, exception, or jump out) from this expression. */ >> DEFTREECODE (TRY_FINALLY_EXPR, "try_finally", tcc_statement, 2) >> + >> +/* Evaluate either the normal or the exceptional cleanup. This must >> + only be present as the cleanup expression in a TRY_FINALLY_EXPR. >> + If the TRY_FINALLY_EXPR completes normally, the first operand of >> + EH_ELSE is used as a cleanup, otherwise the second operand is >> + used. */ >> +DEFTREECODE (EH_ELSE, "eh_else", tcc_statement, 2) > It's a bit weird that this is a tcc_statement as opposed to tcc_expression, Erhm... What's weird about it? It is not something that belongs in an arbitrary expr, it's a lot more like a top-level statement, like try_finally, having side effects but no useful value. > also I'd have called it EH_ELSE_EXPR for clarity. Now *that* would be weird IMHO. No offense intended, but I'd have dropped the _EXPR from TRY_FINALLY_EXPR to make it match the "try_finally" string. What reasons are there for them to deserve the _EXPR suffix? If I rename it to EH_ELSE_EXPR, should GIMPLE_EH_ELSE also get a _EXPR suffix? > I also wonder why TRY_FINALLY_EXPR didn't just get a third optional > operand? I considered that possibility, but I didn't expect EH_ELSE to be used often enough to bloat every TRY_FINALLY_EXPR with another operand, plus a flag or some other means to remove ambiguity between same-cleanup and no-else-cleanup. -- Alexandre Oliva, freedom fighter he/him https://FSFLA.org/blogs/lxo Be the change, be Free! FSF Latin America board member GNU Toolchain Engineer Free Software Evangelist Hay que enGNUrecerse, pero sin perder la terGNUra jamás - Che GNUevara
