[Bug fortran/29216] New: Derived type components of function results are not initialised

[Bug fortran/29216] New: Derived type components of function results are not initialised

[stephan dot kramer at imperial dot ac dot uk]

The derived type components of function results are not initialised according
to their initialisation statements. This follows from the following code:

program test
implicit none

  type A
    integer, pointer:: p => null()
    integer:: i=3
  end type A

  type(A):: x,y

  print *,associated(x%p), x%i
  x=f()
  print *,associated(x%p), x%i

contains

function f()
type(A):: f

  print *, associated(f%p), f%i

end function f

end program

and run-time output:

 F           3
 T -1073745616
 T -1073745616


-- 
           Summary: Derived type components of function results are not
                    initialised
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: stephan dot kramer at imperial dot ac dot uk


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29216

[Bug fortran/29216] Derived type components of function results are not initialised

[pault at gcc dot gnu dot org]

------- 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


Administrator@NONE-X6EIN5I8FN /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|0000-00-00 00:00:00         |2006-09-25 16:29:41
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29216

[Bug fortran/29216] Derived type components of function results are not initialised

[pault at gcc dot gnu dot org]

------- 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=12397&action=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

[fxcoudert at gcc dot gnu dot org]

------- 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

[pault at gcc dot gnu dot org]

------- 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

[pault at gcc dot gnu dot org]

------- 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=12406&action=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

[pault at gcc dot gnu dot org]

------- 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=12446&action=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

[pault at gcc dot gnu dot org]

------- 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=12449&action=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

[patchapp at dberlin dot org]

------- 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

[patchapp at dberlin dot org]

------- 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

[pault at gcc dot gnu dot org]

------- 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=gcc&view=rev&rev=117879
Log:
2006-10-19  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
        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  <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.


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

[pault at gcc dot gnu dot org]

------- 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

[pault at gcc dot gnu dot org]

------- 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=gcc&view=rev&rev=118666
Log:
2006-11-10 Paul Thomas <pault@gcc.gnu.org>

        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 <pault@gcc.gnu.org>

        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