This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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 - Default initialization for fucntion results and intent OUT automatic arrays.


:ADDPATCH fortran:

This patch fixes two places where default initializers were not being applied but should
be; function results and intent OUT 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.

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.

I was going to add an extension of this patch to permit initialization to null of all
variables that would not otherwise be initialized.  I will do this at a later date, once
we are working with 4.3.0.

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?

Paul

2006-10-17  Paul Thomas <pault@gcc.gnu.org>

	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
	gfc_trans_assignment.
	* resolve.c (resolve_allocate_exp): Replace EXEC_ASSIGN by
	EXEC_INIT_ASSIGN.
	(resolve_code): EXEC_INIT_ASSIGN does not need resolution.
	(apply_default_init): New function.
	(resolve_symbol): Call it for derived type function results
	and for INTENT_OUT dummies.
	* st.c (gfc_free_statement): Include EXEC_INIT_ASSIGN.

2006-10-17  Paul Thomas  <pault@gcc.gnu.org>

	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]