[Patch, Fortran] PR 54107: [4.8 Regression] Memory hog with abstract interface
Janus Weil
janus@gcc.gnu.org
Sun Jan 27 18:49:00 GMT 2013
Hi all,
the attached patch fixes a regression with PROCEDURE declarations and
is a co-production of Mikael and me. The problem is this: For a
procedure declaration like
PROCEDURE(ifc) :: proc
we currently go to quite some lengths to copy the complete interface
(i.e. formal args etc) from symbol 'ifc' to the just declared symbol
'proc'. If done properly (which only happens as of lately), this will
result in an infinite loop for declarations like this:
subroutine sub (arg)
procedure(sub) :: arg
end subroutine
Here the argument is a procedure which inherits its interface from the
host subroutine (so that the interface of 'sub' is defined
'recursively', so to speak), and we just keep building an infinite
chain of symbols.
The simple and effective solution to this problem is to avoid the
complete copying procedure altogether and to just keep a pointer to
the interface (which we have anyway: ts.interface). This even
simplifies a few things and allows us to get rid of some code parts.
In turn, we have to make sure to use the formal args not from the
symbol itself, but from its interface (ts.interface). This is what the
new function 'gfc_sym_get_dummy_args' does.
This new approach also allows us to get rid of the 'formal' and
'formal_ns' in gfc_components (which are now available via
ts.interface). This also means we don't have to read those from the
mod files any more, which therefore change their format.
What confuses me: While our documentation claims that the module
format has been changed for 4.8 (see
http://gcc.gnu.org/wiki/GFortran#GCC4.8 and
http://gcc.gnu.org/gcc-4.8/changes.html), I see in module.c:
#define MOD_VERSION "9"
in both 4.8 and trunk. Can anyone tell me why the documentation does
not match the implementation? Or am I missing something?
Anyway, should we bump the mod version with this patch, or should we
rather avoid it?
The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2013-01-27 Janus Weil <janus@gcc.gnu.org>
Mikael Morin <mikael@gcc.gnu.org>
PR fortran/54107
* gfortran.h (gfc_component): Delete members 'formal' and 'formal_ns'.
(gfc_copy_formal_args,gfc_copy_formal_args_ppc,gfc_expr_replace_symbols,
gfc_expr_replace_comp): Delete.
(gfc_sym_get_dummy_args): New prototype.
* dependency.c (gfc_check_fncall_dependency): Use
'gfc_sym_get_dummy_args'.
* expr.c (gfc_is_constant_expr): Ditto.
(replace_symbol,gfc_expr_replace_symbols,replace_comp,
gfc_expr_replace_comp): Deleted.
* frontend-passes.c (doloop_code,do_function): Use
'gfc_sym_get_dummy_args'.
* interface.c (gfc_check_operator_interface,gfc_compare_interfaces,
gfc_procedure_use,gfc_ppc_use,gfc_arglist_matches_symbol,
gfc_check_typebound_override): Ditto.
* module.c (mio_component): Do not read/write 'formal' and 'formal_ns'.
* resolve.c (resolve_procedure_interface,resolve_fl_derived0): Do not
copy formal args, but just keep a pointer to the interface.
(resolve_function,resolve_call,resolve_typebound_generic_call,
resolve_ppc_call,resolve_expr_ppc,generate_component_assignments,
resolve_fl_procedure,gfc_resolve_finalizers,check_generic_tbp_ambiguity,
resolve_typebound_procedure,check_uop_procedure): Use
'gfc_sym_get_dummy_args'.
* symbol.c (free_components): Do not free 'formal' and 'formal_ns'.
(gfc_copy_formal_args,gfc_copy_formal_args_ppc): Deleted.
(gfc_sym_get_dummy_args): New function.
* trans-array.c (get_array_charlen,gfc_walk_elemental_function_args):
Use 'gfc_sym_get_dummy_args'.
* trans-decl.c (build_function_decl,create_function_arglist,
build_entry_thunks,init_intent_out_dt,gfc_trans_deferred_vars,
add_argument_checking): Ditto.
* trans-expr.c (gfc_map_fcn_formal_to_actual,gfc_conv_procedure_call,
gfc_conv_statement_function): Ditto.
* trans-stmt.c (gfc_conv_elemental_dependencies): Ditto.
* trans-types.c (create_fn_spec,gfc_get_function_type): Ditto.
2013-01-27 Janus Weil <janus@gcc.gnu.org>
Mikael Morin <mikael@gcc.gnu.org>
PR fortran/54107
* gfortran.dg/proc_ptr_comp_36.f90: New.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr54107_v4.diff
Type: application/octet-stream
Size: 37609 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20130127/813dfafa/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: proc_ptr_comp_36.f90
Type: application/octet-stream
Size: 575 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20130127/813dfafa/attachment-0001.obj>
More information about the Fortran
mailing list