http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56218
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2013-02-06
CC| |janus at gcc dot gnu.org
Summary|Segfault with allocatable |[OOP] Segfault with
|intent(out) derived type |allocatable intent(out)
|argument having allocatable |derived type argument
|component |having allocatable
| |component
Ever Confirmed|0 |1
--- Comment #1 from janus at gcc dot gnu.org 2013-02-06 09:26:59 UTC ---
Confirmed. I get a runtime segfault with 4.6, 4.7 and trunk (though with 4.6 it
seems to be slightly different).
Further reduced test case:
program test_poly
implicit none
type :: foo_t
real, allocatable :: a(:)
end type
class(foo_t), allocatable :: f
call do_stuff(f)
contains
subroutine do_stuff (f)
class(foo_t), intent(out), allocatable :: f
end subroutine
end program
The dump shows the following:
do_stuff (struct __class_test_poly_Foo_t_a & restrict f)
{
if (f->_data->a.data != 0B)
{
__builtin_free ((void *) f->_data->a.data);
}
f->_data->a.data = 0B;
}
So the problem is clear: Before freeing the allocatable components, we do not
check whether 'f->_data' is null (i.e. whether 'f' is allocated at all).
