RFC: Rework local variable clean-up code and use try-finally
Paul Richard Thomas
paul.richard.thomas@gmail.com
Thu Jul 8 20:26:00 GMT 2010
Dear Daniel,
......snip.....
> try
> {
> init_a;
> init_b;
> init_c;
> body code;
> }
> finally
> {
> clean_up_a;
> clean_up_b;
> clean_up_c;
> }
I like it very much. From tree.def:
/* Evaluate the first operand.
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)
example
try_fin = build2 (TRY_FINALLY_EXPR, void_type_node, stmt1, stmt2);
from what I have understood, mudflap must be enabled to have this. To
be honest, I do not even know if it is or not for gfortran
> (Note the reversed order of clean-ups.) Would this also be possible (i.e.,
> a/b/c are "independent of each other" so that clean_up_c does not depend on
> a still available) or does this lead to problems in special situations?
> What do you think? (Of course, the original version is cleaner and nicer
> -- but if this is also possible, it may be easier to do because we can just
> always add the new blocks to the end of init/clean_up. Are there routines
> to add expressions to the *front* of a tree?)
I think that you should honour the reverse ordering of finalization so
that structures, of one kind or another, are correctly dealt with.
I would pile them up as in gfc_trans_deferred_vars in trans-decl.c.
However, the block handling functions in trans.c should tell you
enough the make a gfc_add_expr_to_front_of_tree :-)
Cheers
Paul
--
The knack of flying is learning how to throw yourself at the ground and miss.
--Hitchhikers Guide to the Galaxy
More information about the Fortran
mailing list