This is the mail archive of the gcc-bugs@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]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]