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