[Bug fortran/29216] Derived type components of function results are not initialised
--- Comment #12 from pault at gcc dot gnu dot org 2006-11-10 21:52 --- Subject: Bug 29216 Author: pault Date: Fri Nov 10 21:52:00 2006 New Revision: 118666 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118666 Log: 2006-11-10 Paul Thomas [EMAIL PROTECTED] Backport from mainline. PR fortran/29371 * trans-expr.c (gfc_trans_pointer_assignment): Add the expression for the assignment of null to the data field to se-pre, rather than block. PR fortran/29392 * data.c (create_character_intializer): Copy and simplify the expressions for the start and end of a sub-string reference. PR fortran/29216 PR fortran/29314 * gfortran.h : Add EXEC_INIT_ASSIGN. * dump-parse-tree.c (gfc_show_code_node): The same. * trans-expr.c (gfc_trans_init_assign): New function. * trans-stmt.h : Add prototype for gfc_trans_init_assign. * trans.c (gfc_trans_code): Implement EXEC_INIT_ASSIGN. * 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. PR fortran/29387 * trans-intrinsic.c (gfc_conv_intrinsic_len): Rearrange to have a specific case for EXPR_VARIABLE and, in default, build an ss to call gfc_conv_expr_descriptor for array expressions.. PR fortran/29490 * trans-expr.c (gfc_set_interface_mapping_bounds): In the case that GFC_TYPE_ARRAY_LBOUND is not available, use descriptor values for it and GFC_TYPE_ARRAY_UBOUND. PR fortran/29641 * trans-types.c (gfc_get_derived_type): If the derived type namespace has neither a parent nor a proc_name, set NULL for the search namespace. PR fortran/24518 * trans-intrinsic.c (gfc_conv_intrinsic_mod): Use built_in fmod for both MOD and MODULO, if it is available. PR fortran/29565 * trans-expr.c (gfc_conv_aliased_arg): For an INTENT(OUT), save the declarations from the unused loops by merging the block scope for each; this ensures that the temporary is declared. 2006-11-10 Paul Thomas [EMAIL PROTECTED] PR fortran/29371 * gfortran.dg/nullify_3.f90: New test. PR fortran/29392 * gfortran.dg/data_char_3.f90: New test. PR fortran/29216 * gfortran.dg/result_default_init_1.f90: New test. PR fortran/29314 * gfortran.dg/automatic_default_init_1.f90: New test. PR fortran/29387 * trans-intrinsic.c (gfc_conv_intrinsic_len): Rearrange to have a specific case for EXPR_VARIABLE and, in default, build an ss to call gfc_conv_expr_descriptor for array expressions.. PR fortran/29490 * trans-expr.c (gfc_set_interface_mapping_bounds): In the case that GFC_TYPE_ARRAY_LBOUND is not available, use descriptor values for it and GFC_TYPE_ARRAY_UBOUND. PR fortran/29641 * trans-types.c (gfc_get_derived_type): If the derived type namespace has neither a parent nor a proc_name, set NULL for the search namespace. PR fortran/29565 * gfortran.dg/gfortran.dg/aliasing_dummy_3.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/actual_array_interface_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/aliasing_dummy_3.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/automatic_default_init_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/data_char_3.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/intrinsic_actual_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/nullify_3.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/result_default_init_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/used_types_11.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/used_types_12.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/data.c branches/gcc-4_1-branch/gcc/fortran/dump-parse-tree.c branches/gcc-4_1-branch/gcc/fortran/f95-lang.c branches/gcc-4_1-branch/gcc/fortran/gfortran.h branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/st.c branches/gcc-4_1-branch/gcc/fortran/trans-expr.c branches/gcc-4_1-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.h branches/gcc-4_1-branch/gcc/fortran/trans-types.c branches/gcc-4_1-branch/gcc/fortran/trans.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29216
[Bug fortran/29216] Derived type components of function results are not initialised
--- Comment #11 from pault at gcc dot gnu dot org 2006-10-19 06:42 --- Fixed on trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29216
[Bug fortran/29216] Derived type components of function results are not initialised
--- Comment #9 from patchapp at dberlin dot org 2006-10-18 11:20 --- Subject: Bug number PR29216 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00900.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29216
[Bug fortran/29216] Derived type components of function results are not initialised
--- Comment #10 from pault at gcc dot gnu dot org 2006-10-19 04:51 --- Subject: Bug 29216 Author: pault Date: Thu Oct 19 04:51:14 2006 New Revision: 117879 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117879 Log: 2006-10-19 Paul Thomas [EMAIL PROTECTED] 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 argument for gfc_trans_assignment to false. * trans-stmt.c (gfc_trans_forall_1): The same. * trans-expr.c (gfc_conv_function_call, gfc_trans_assign, gfc_trans_arrayfunc_assign, gfc_trans_assignment): The same. In the latter function, use the new flag to stop the checking of the lhs for deallocation. (gfc_trans_init_assign): New function. * 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-19 Paul Thomas [EMAIL PROTECTED] 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. Added: trunk/gcc/testsuite/gfortran.dg/automatic_default_init_1.f90 trunk/gcc/testsuite/gfortran.dg/result_default_init_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/st.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-openmp.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans-stmt.h trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/alloc_comp_basics_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29216
[Bug fortran/29216] Derived type components of function results are not initialised
--- Comment #8 from patchapp at dberlin dot org 2006-10-17 14:05 --- Subject: Bug number PR29216 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00852.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29216
[Bug fortran/29216] Derived type components of function results are not initialised
--- Comment #6 from pault at gcc dot gnu dot org 2006-10-16 16:51 --- Created an attachment (id=12446) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12446action=view) Fix for this and PR29394 As well as fixing these PRs, this patch provides an option -finitialize-null, which does just that to all variables. I am just about to apply it to workstation's tree and will submit it tonight after another round of regtetsing. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Attachment #12406|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29216
[Bug fortran/29216] Derived type components of function results are not initialised
--- Comment #7 from pault at gcc dot gnu dot org 2006-10-17 04:55 --- Created an attachment (id=12449) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12449action=view) Patch without initialization option I have had to drop -finitialize-null due to problems in testing. I will have another try in the coming weeks. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29216
[Bug fortran/29216] Derived type components of function results are not initialised
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-10-10 07:56 --- Paul, I'm not sure, but I think PR29394 is related to that one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29216
[Bug fortran/29216] Derived type components of function results are not initialised
--- Comment #4 from pault at gcc dot gnu dot org 2006-10-10 12:48 --- (In reply to comment #3) Paul, I'm not sure, but I think PR29394 is related to that one. Yes, I already verified that yesterday but forgot to make a note of it. I'm just gearing up to an afternoon of gfortran submits - I am doing garde-enfant duty. Thanks Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29216
[Bug fortran/29216] Derived type components of function results are not initialised
--- Comment #5 from pault at gcc dot gnu dot org 2006-10-10 20:49 --- Created an attachment (id=12406) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12406action=view) A development of the previous patch (ie. it works!). This now regtests, apart from alloc_comp_basics_1.f90, which is upset by further allocates and deallocates - it runs but its accounting is thrown. As FX mentions, this patch can also fix PR29394 and others of its ilk. It is also a model for default initialization of all variables that are not otherwise initialized. For this reason, I am going to sit on this for a little while yet, so that I can develop these features. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Attachment #12397|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29216
[Bug fortran/29216] Derived type components of function results are not initialised
--- Comment #2 from pault at gcc dot gnu dot org 2006-10-08 22:03 --- Created an attachment (id=12397) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12397action=view) Preliminary fix for this PR This has only been tested against the reporter's example. Regtesting and checking against other case (eg. arrays or characters) will follow in the next couple of days. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29216
[Bug fortran/29216] Derived type components of function results are not initialised
--- Comment #1 from pault at gcc dot gnu dot org 2006-09-25 16:29 --- Yup, does it for me too! Confirmed. As soon as I am near no an F95 standard, I will confirm that a function result should indeed be initialized; logic suggests that it should! Paul $ /irun/bin/gfortran --version GNU Fortran 95 (GCC) 4.2.0 20060919 (experimental) Copyright (C) 2006 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING [EMAIL PROTECTED] /home/alloc_comps $ ./a F 3 T 1628825276 T 1628825276 -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-25 16:29:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29216
