[Bug fortran/59781] New: Incorrect initialisation of derived type

[Bug fortran/59781] New: Incorrect initialisation of derived type

[james.s.spencer at gmail dot com]

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

            Bug ID: 59781
           Summary: Incorrect initialisation of derived type
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: james.s.spencer at gmail dot com

Created attachment 31818
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31818&action=edit
Tarball containing example code, tree produced by gfortran 4.8.2 and Makefile.

(Complete modules and a makefile is attached.  Also confirmed against 4.6.3)

With the definition

type dSFMT_t
    private
    type(c_ptr) :: dSFMT_state = c_null_ptr
    real(c_double), allocatable :: random_store(:)
end type dSFMT_t

the dSFMT_t objects in the following module should both be initialised with a
null pointer for the dSFMT_state component:

module hilbert_space
implicit none
contains
    subroutine test_rng()
        use dSFMT_interface
        type(dSFMT_t) :: rng
        call dSFMT_init(7, 50000, rng)
    end subroutine test_rng
    subroutine estimate_hilbert_space()
        use dSFMT_interface
        type(dSFMT_t) :: rng
        call dSFMT_init(7, 50000, rng)
    end subroutine estimate_hilbert_space
end module hilbert_space

Instead only the rng object in estimate_hilbert_space is correctly initialised.
 The relevant parts of the tree are:

estimate_hilbert_space ()                                                       
{                                                                               
  struct dsfmt_t rng;                                                           

  try                                                                           
    {                                                                           
      {                                                                         
        struct dsfmt_t dsfmt_t.0;                                               

        dsfmt_t.0.dsfmt_state = 0B;                                             
        dsfmt_t.0.random_store.data = 0B;                                       
        rng = dsfmt_t.0;                                                        
      }                                                                         
      [...]
    }                                                                           
}                                                                               


test_rng ()                                                                     
{                                                                               
  struct dsfmt_t rng;                                                           

  try                                                                           
    {                                                                           
      rng.random_store.data = 0B;
      [...]
    }                                                                           
}     


This bug is tricky to observe---small changes to the code (e.g. making rng a
pointer, code reorganisation, having additional or fewer procedures in the same
file, removing the random_store allocatable component etc. can lead to the
dSFMT_t objects being correctly initialised.  I had the above code (with
additions) in a large code base for several months until an innocuous
refactoring revealed it.

See also discussion at
https://groups.google.com/forum/#!topic/comp.lang.fortran/WogpvhUny4c, where
Janus posted a smaller example which breaks under gfortran trunk.

[Bug fortran/59781] [4.9 Regression] [F03] Incorrect initialisation of derived type

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-01-12
                 CC|                            |janus at gcc dot gnu.org
            Summary|Incorrect initialisation of |[4.9 Regression] [F03]
                   |derived type                |Incorrect initialisation of
                   |                            |derived type
     Ever confirmed|0                           |1

--- Comment #1 from janus at gcc dot gnu.org ---
(In reply to james.s.spencer from comment #0)
> See also discussion at
> https://groups.google.com/forum/#!topic/comp.lang.fortran/WogpvhUny4c, where
> Janus posted a smaller example which breaks under gfortran trunk.

namely this one (which apparently is a regression in 4.9 trunk):

module hilbert_space
  use, intrinsic :: iso_c_binding
  implicit none

  type dSFMT_t
    type(c_ptr) :: dSFMT_state = c_null_ptr
    real(c_double), allocatable :: random_store(:)
  end type

contains

  subroutine dSFMT_init (arg)
    type(dSFMT_t) :: arg
  end subroutine

  subroutine test_rng()
    type(dSFMT_t) :: rng
    call dSFMT_init (rng)
  end subroutine

end module

[Bug fortran/59781] [4.9 Regression] [F03] Incorrect initialisation of derived type

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org ---
Here is a reduced test case of comment 0, which shows the wrong dump with all
gfortran versions I tried (4.4, 4.6, 4.7, 4.8 and trunk):


module dSFMT_interface

  use, intrinsic :: iso_c_binding
  implicit none

  type dSFMT_t
    type(c_ptr) :: state = c_null_ptr
    real(c_double), allocatable :: store(:)
  end type

end module


  use dSFMT_interface
  implicit none

contains

  subroutine dSFMT_init(rng)
    type(dSFMT_t) :: rng
  end subroutine

  subroutine test_rng()
    type(dSFMT_t) :: rng
    call dSFMT_init(rng)
  end subroutine

end



It is very similar to comment 1, just that the derived type is defined in a
separate module.

[Bug fortran/59781] [4.7/4.8/4.9 Regression] [F03] Incorrect initialisation of derived type

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.9.0
            Summary|[4.9 Regression] [F03]      |[4.7/4.8/4.9 Regression]
                   |Incorrect initialisation of |[F03] Incorrect
                   |derived type                |initialisation of derived
                   |                            |type

--- Comment #3 from janus at gcc dot gnu.org ---
I verified that the problem is not specific to ISO_C_BINDING and occurs also
when replacing type(c_ptr) by some other derived type.

The following variant works with 4.4 (printing '1' as expected), but fails with
4.6 and above (printing some random number):


  implicit none

  type t1
    integer :: s
  end type

  type t2
    type(t1) :: state = t1(1)
    real, allocatable :: store(:)
  end type

  call test

contains

  subroutine test
    type(t2) :: rng
    print *,rng%state%s
  end subroutine

end

[Bug fortran/59781] [4.7/4.8/4.9 Regression] [F03] Incorrect initialisation of derived type

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
The code in comment 3 gives 1 without valgrind error when compiled with
gfortran 4.5.4.
For 4.6 (r158252) and 4.7.3 valgrind gives

==69121== Conditional jump or move depends on uninitialised value(s)
==69121==    at 0x1000E7CC5: gfc_itoa (in
/opt/gcc/gcc4.6p/lib/libgfortran.3.dylib)
==69121==    by 0x7FFF5FBFE89F: ???
==69121==    by 0x2: ???

and 4.8.2 and trunk gives

==69150== Conditional jump or move depends on uninitialised value(s)
==69150==    at 0x1000ED847: gfc_itoa (in
/sw64/lib/gcc4.8/lib/libgfortran.3.dylib)
==69150==    by 0x100000EB1: main (in ./a.out)
==69150== 
==69150== Conditional jump or move depends on uninitialised value(s)
==69150==    at 0x1000ED84C: gfc_itoa (in
/sw64/lib/gcc4.8/lib/libgfortran.3.dylib)
==69150==    by 0x100000EB1: main (in ./a.out)
==69150== 
==69150== Conditional jump or move depends on uninitialised value(s)
==69150==    at 0x1002D1AA1: __udivmodti4 (in /usr/lib/libSystem.B.dylib)
==69150==    by 0x1002D1F9B: __umodti3 (in /usr/lib/libSystem.B.dylib)
==69150== 
==69150== Conditional jump or move depends on uninitialised value(s)
==69150==    at 0x1002D1AA1: __udivmodti4 (in /usr/lib/libSystem.B.dylib)
==69150==    by 0x1000ED88C: gfc_itoa (in
/sw64/lib/gcc4.8/lib/libgfortran.3.dylib)
==69150== 
==69150== Conditional jump or move depends on uninitialised value(s)
==69150==    at 0x1000ED899: gfc_itoa (in
/sw64/lib/gcc4.8/lib/libgfortran.3.dylib)
==69150== 
==69150== Conditional jump or move depends on uninitialised value(s)
==69150==    at 0x100012AF9: strlen (mc_replace_strmem.c:398)
==69150==    by 0x1000ED95E: write_integer (in
/sw64/lib/gcc4.8/lib/libgfortran.3.dylib)
==69150==    by 0x100000EB1: main (in ./a.out)
==69150== 
==69150== Conditional jump or move depends on uninitialised value(s)
==69150==    at 0x100012B07: strlen (mc_replace_strmem.c:398)
==69150==    by 0x1000ED95E: write_integer (in
/sw64/lib/gcc4.8/lib/libgfortran.3.dylib)
==69150==    by 0x100000EB1: main (in ./a.out)
==69150== 
==69150== Syscall param write(buf) points to uninitialised byte(s)
==69150==    at 0x1001A4272: write (in /usr/lib/libSystem.B.dylib)
==69150==    by 0x1000EAA09: raw_write (in
/sw64/lib/gcc4.8/lib/libgfortran.3.dylib)
==69150==    by 0x10045075F: ???
==69150==  Address 0x100450ba8 is 8 bytes inside a block of size 512 alloc'd
==69150==    at 0x100012679: malloc (vg_replace_malloc.c:266)
==69150==    by 0x100020304: _gfortrani_xmalloc (in
/sw64/lib/gcc4.8/lib/libgfortran.3.dylib)
==69150==    by 0x1FFFF: ???
==69150==    by 0x1000209AC: _gfortrani_fbuf_init (in
/sw64/lib/gcc4.8/lib/libgfortran.3.dylib)
==69150==

[Bug fortran/59781] [4.7/4.8/4.9 Regression] [F03] Incorrect initialisation of derived type

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4
                 CC|                            |jakub at gcc dot gnu.org

[Bug fortran/59781] [4.7/4.8/4.9 Regression] [F03] Incorrect initialisation of derived type

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
Here is a draft patch which seems to fix comment 1 to 3:


Index: gcc/fortran/trans-decl.c
===================================================================
--- gcc/fortran/trans-decl.c    (revision 206579)
+++ gcc/fortran/trans-decl.c    (working copy)
@@ -4005,8 +4005,6 @@ gfc_trans_deferred_vars (gfc_symbol * proc_sym, gf
     }
       else if (sym->ts.deferred)
     gfc_fatal_error ("Deferred type parameter not yet supported");
-      else if (alloc_comp_or_fini)
-    gfc_trans_deferred_array (sym, block);
       else if (sym->ts.type == BT_CHARACTER)
     {
       gfc_save_backend_locus (&loc);
@@ -4017,6 +4015,18 @@ gfc_trans_deferred_vars (gfc_symbol * proc_sym, gf
         gfc_trans_auto_character_variable (sym, block);
       gfc_restore_backend_locus (&loc);
     }
+      else if (sym->ts.type == BT_DERIVED)
+    {
+      if (alloc_comp_or_fini)
+        gfc_trans_deferred_array (sym, block);
+      if (sym->value && !sym->attr.data && sym->attr.save == SAVE_NONE)
+        {
+          gfc_start_block (&tmpblock);
+          gfc_init_default_dt (sym, &tmpblock, false);
+          gfc_add_init_cleanup (block, gfc_finish_block (&tmpblock),
+                    NULL_TREE);
+        }
+    }
       else if (sym->attr.assign)
     {
       gfc_save_backend_locus (&loc);
@@ -4024,16 +4034,6 @@ gfc_trans_deferred_vars (gfc_symbol * proc_sym, gf
       gfc_trans_assign_aux_var (sym, block);
       gfc_restore_backend_locus (&loc);
     }
-      else if (sym->ts.type == BT_DERIVED
-         && sym->value
-         && !sym->attr.data
-         && sym->attr.save == SAVE_NONE)
-    {
-      gfc_start_block (&tmpblock);
-      gfc_init_default_dt (sym, &tmpblock, false);
-      gfc_add_init_cleanup (block, gfc_finish_block (&tmpblock),
-                NULL_TREE);
-    }
       else if (!(UNLIMITED_POLY(sym)))
     gcc_unreachable ();
     }


I have not regtested it yet. One minor remaining problem is that the
allocatable component is nullified twice now.

[Bug fortran/59781] [4.7/4.8/4.9 Regression] [F03] Incorrect initialisation of derived type

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org ---
(In reply to janus from comment #5)
> Here is a draft patch which seems to fix comment 1 to 3:

Unfortunately it does produce a few failures in the coarray sector:

FAIL: gfortran.dg/coarray/alloc_comp_1.f90 -fcoarray=single  -O2  (internal
compiler error)
FAIL: gfortran.dg/coarray/lib_realloc_1.f90 -fcoarray=single  -O2  (internal
compiler error)
FAIL: gfortran.dg/coarray/subobject_1.f90 -fcoarray=single  -O2  (internal
compiler error)
FAIL: gfortran.dg/coarray_lib_realloc_1.f90  -O  (internal compiler error)

[Bug fortran/59781] [4.7/4.8/4.9/4.10 Regression] [F03] Incorrect initialisation of derived type

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.0                       |4.9.1

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.0 has been released

[Bug fortran/59781] [4.8/4.9/4.10 Regression] [F03] Incorrect initialisation of derived type

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59781

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.1                       |4.9.2

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.1 has been released.

[Bug fortran/59781] [4.8/4.9/5 Regression] [F03] Incorrect initialisation of derived type

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59781

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.2                       |4.9.3

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.2 has been released.

[Bug fortran/59781] [4.9/5/6 Regression] [F03] Incorrect initialisation of derived type

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59781

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.3 has been released.

[Bug fortran/59781] [4.9/5/6 Regression] [F03] Incorrect initialisation of derived type

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59781

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.3                       |4.9.4