[Bug fortran/56218] [OOP] Segfault with allocatable intent(out) derived type argument having allocatable component

[janus at gcc dot gnu.org]

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).