This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/59781] New: Incorrect initialisation of derived type
- From: "james.s.spencer at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sun, 12 Jan 2014 21:26:53 +0000
- Subject: [Bug fortran/59781] New: Incorrect initialisation of derived type
- Auto-submitted: auto-generated
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.