This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, fortran] PR32665 - allocatable array on lhs deleted while still in use on rhs
- From: Tobias Burnus <burnus at net-b dot de>
- To: Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>
- Cc: "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>, gcc-patches List <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 16 Jul 2007 20:20:34 +0200
- Subject: Re: [Patch, fortran] PR32665 - allocatable array on lhs deleted while still in use on rhs
- References: <339c37f20707160243o5fcd4097wc9348e1b8089d4bd@mail.gmail.com>
:REVIEWMAIL:
Paul Richard Thomas wrote:
> (i) An array constructor, used as an argument in the constructor of a
> structure with allocatable components, yielded incorrect bounds for
> the allocatable component. This manifests itself as memory leaks, bad
> accesses and segfaults at runtime (PR31320).
> (ii) The dependency between the rhs and lhs, where the lhs appears as
> a reference in its own constructor, led to an ICE because the array
> was deallocated at the start of the assignment.
> Regtested on Cygwin_NT/amd64 - does not break cp2k - OK for trunk?
OK. Thanks for the fix.
Tobias
Side remark: The generated executable leaks memory:
96 bytes in 1 blocks are definitely lost in loss record 1 of 2
at 0x4C22D06: malloc (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
by 0x40122B: MAIN__ (alloc_comp_assign_2.f90:11)
by 0x401EEB: main (fmain.c:22)
96 bytes in 1 blocks are definitely lost in loss record 2 of 2
at 0x4C22D06: malloc (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
by 0x400BCA: MAIN__ (alloc_comp_assign_2.f90:10)
by 0x401EEB: main (fmain.c:22)
for this stripped down test case:
type :: a
integer, allocatable :: i(:)
end type a
type :: b
type (a), allocatable :: at(:)
end type b
type(a) :: x(2)
type(b) :: y(2)
integer i
y(1) = b ((/x(1),x(2)/))
y(2) = b ((/x(2),x(1)/))
forall (i=1:2) y(i) = b ((/x(i)/))
end