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] |
: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? Paul 2006-10-18 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 types that become defined but which do not already have an initialization expression.. * st.c (gfc_free_statement): Include EXEC_INIT_ASSIGN. 2006-10-18 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] |