On Fri, Jun 28, 2019 at 5:21 AM Alexandre Oliva <ol...@adacore.com> wrote: > > 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.
It's weird because it appears in a TRY_FINALLY statement operand. But I guess the line between statements and expressions in GENERIC is muddy... > > 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. OK, let me say for consistency then ... > What reasons are there for them to deserve the _EXPR suffix? History I guess? All 'old' tcc_statement are _EXPR. > 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. Fair enough. Richard. > > -- > 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
