[Bug fortran/57957] [F03] Double free with allocatable components

2015-10-20 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57957

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Dominique d'Humieres  ---
> Confirmed for gcc 5 and trunk (6.0). The test in comment 0 succeeds with 
> 4.9.2,
> but not the one in comment 2 (!?). Both tests fail with 4.8.5.

The first test has been fixed between revisions r199435 (2013-05-30) and
r199960 (2013-06-11) and the second test between r219797 (2015-01-17) and
r219823 (2015-01-18). Closing as FIXED.


[Bug fortran/57957] [F03] Double free with allocatable components

2015-04-18 Thread mikael at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57957

Mikael Morin mikael at gcc dot gnu.org changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #4 from Mikael Morin mikael at gcc dot gnu.org ---
(In reply to janus from comment #2)
 Updated test case:
 
That one seems to be memory-clean with current trunk.  FIXED?


[Bug fortran/57957] [F03] Double free with allocatable components

2015-04-18 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57957

--- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr ---
 That one seems to be memory-clean with current trunk.  FIXED?

Confirmed for gcc 5 and trunk (6.0). The test in comment 0 succeeds with 4.9.2,
but not the one in comment 2 (!?). Both tests fail with 4.8.5.


[Bug fortran/57957] [F03] Double free with allocatable components

2013-10-25 Thread songtao.thu at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57957

--- Comment #3 from Tao Song songtao.thu at gmail dot com ---
(In reply to janus from comment #2)
 (In reply to Tobias Burnus from comment #1) 
  For GCC 4.9, one needs to wrap the code in the main program in BLOCK/END
  BLOCK as otherwise the end-of-scope deallocation does not trigger, which
  causes the failure.
 
 Updated test case:
 
 
 program main
 
   implicit none
 
   type :: type1
 real, allocatable :: anum(:)
   end type
 
   type :: type2
 type(type1) :: temp
   end type
 
 
   block
 type(type1) :: t1
 type(type2) :: t2
 
 t1 = type1([0.,1.])
 t2 = type2(t1)
   end block
 end
 
 
 
 Note: The double free goes away when changing the line
 
 t2 = type2(t1)
 
 to
 
 t2%temp = t1
 
 That means the actual problem is not the auto-dealloc itself (which is done
 properly), but the construction of t2: With the second variant, a deep copy
 is done (allocating a separate chunk of memory for t2%temp), while in the
 first one t2%temp only gets a reference to the memory allocated for t1
 (which is of course wrong). Since both t1 and t2 are auto-deallocated, we
 try to free that memory twice.

Do you mean in fortran the default structure constructor would yield a shadow
copying? Is this in the standard?

Thank you.

Tao Song


[Bug fortran/57957] [F03] Double free with allocatable components

2013-08-21 Thread janus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57957

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org
Summary|Double free with|[F03] Double free with
   |allocatable components  |allocatable components

--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #1) 
 For GCC 4.9, one needs to wrap the code in the main program in BLOCK/END
 BLOCK as otherwise the end-of-scope deallocation does not trigger, which
 causes the failure.

Updated test case:


program main

  implicit none

  type :: type1
real, allocatable :: anum(:)
  end type

  type :: type2
type(type1) :: temp
  end type


  block
type(type1) :: t1
type(type2) :: t2

t1 = type1([0.,1.])
t2 = type2(t1)
  end block
end



Note: The double free goes away when changing the line

t2 = type2(t1)

to

t2%temp = t1

That means the actual problem is not the auto-dealloc itself (which is done
properly), but the construction of t2: With the second variant, a deep copy is
done (allocating a separate chunk of memory for t2%temp), while in the first
one t2%temp only gets a reference to the memory allocated for t1 (which is of
course wrong). Since both t1 and t2 are auto-deallocated, we try to free that
memory twice.