This is the mail archive of the mailing list for the GNU Fortran project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Patch, fortran] PR29216 & PR29394 - (Redux) Default initialization for derived types that become defined.

:ADDPATCH fortran:

This patch fixes two places where default initializers were not being applied but should
be; function results and non-dummy automatic arrays. If any exist, it will also catch
other cases where default initializers should be applied, according to the rules of
14.7.5 of the standard; ie. the tests are applied as required by the standard and a
default initializer provided if one is not already present.

Thank you to Erik Edelmann for correcting me on this yesterday. The hooks are in place
in this patch for the application of default initializers to all and any derived types
but this does not seem to be the right time to start this kind of activity. I have
tidied up the condition slightly in resolve_symbol but, otherwise, the patch is not
changed.  The <20 bytes to retain the unused INTENT_OUT branch seems like a small
price to pay to keep the condition fully consistent with the standard.

I was going to add an extension of this patch to permit initialization to null of all
variables that would not otherwise be initialized. Again, this can be done later, once
we are working with 4.3.0.

The mechanism used is to detect those symbols requiring default initialization in
resolve_symbol, which calls a new function that gnenerates an assignment of the
initializer to the variable.  Note it was particularly transparent and easy to do this
using frontend, rather than tree expressions, because arrays are always full.  I decided
to use a new version of EXEC_ASSIGN because loads of extra, 'if (data) deallocate's were
being generated for structures with allocatable components.  As it happens, since the
ordinary ALLOCATE is drawn into this scheme, the number of of unnecessary deallocation
expressions is reduced; by 5 in alloc_comp_basics_1.f90, which actually
counts them.

Both the testcases are those of the reporters and alloc_comp_basics_1.f90, of
course, has the deallocate count reduced.

Looking back on it, we should have chosen to use this self-same mechanism for the
nulling and deallocation of structures with allocatable components; this might be
a useful tidy-up for the future. It will be noted that as well as the conditions
required by the standard, that !a->alloc_comp had to be applied to stop the
initialization being repeated. 

Regtested on amd64/Cygwin_NT - OK for trunk?


2006-10-18  Paul Thomas <>

	PR fortran/29216
	PR fortran/29314
	* gfortran.h : Add EXEC_INIT_ASSIGN.
	* dump-parse-tree.c (gfc_show_code_node): The same.
	* trans-openmp.c gfc_trans_omp_array_reduction): Set new
	for gfc_trans_assignment false.
	* trans-stmt.c (gfc_trans_forall_1): The same.
	* trans-stmt.h : Add prototype for gfc_trans_init_assign.
	* trans.c (gfc_trans_code): Implement EXEC_INIT_ASSIGN.
	* trans.h : Add new boolean argument to the prototype of
	* resolve.c (resolve_allocate_exp): Replace EXEC_ASSIGN by
	(resolve_code): EXEC_INIT_ASSIGN does not need resolution.
	(apply_default_init): New function.
	(resolve_symbol): Call it for derived types that become
	defined but which do not already have an initialization
	* st.c (gfc_free_statement): Include EXEC_INIT_ASSIGN.

2006-10-18  Paul Thomas  <>

	PR fortran/29216
	* gfortran.dg/result_default_init_1.f90: New test.

	PR fortran/29314
	* gfortran.dg/automatic_default_init_1.f90: New test.

	* gfortran.dg/alloc_comp_basics_1.f90: Reduce deallocate count
	from 38 to 33.

Attachment: submit.diff
Description: submit.diff

Attachment: Change.Logs
Description: Change.Logs

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]