[Bug fortran/57354] Wrong run-time assignment of allocatable array of derived type with allocatable component

[pault at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57354

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-11-23
           Assignee|unassigned at gcc dot gnu.org      |pault at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #3 from Paul Thomas <pault at gcc dot gnu.org> ---
Created attachment 31280
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31280&action=edit
Preliminary patch

This patch is preliminary since a temporary is produced, for each assignment,
copied to the newly reallocated lhs and then deallocated. Clearly it would be
more efficient to deallocate the lhs and then point the lhs to the temporary.
My first attempt to do this segfaulted because the temporary was still deleted,
in spite of my attempt to suppress it! I will persevere.

The test case will be along the following lines:
! { dg-do run }
!
! PR fortran/57354
!
! Contributed by Vladimir Fuka  <vladimir.fuka@gmail.com>
!
  type t
    integer,allocatable :: i
  end type

  type(t) :: e
  type(t), allocatable :: a(:)
  integer :: chksum = 0

  do i=1,3   ! Was 100 in original
    e%i = i
    chksum = chksum + i
    if (.not.allocated(a)) then
      a = [e]
    else
      call foo
    end if
  end do

  if (sum ([(a(i)%i, i=1,size(a))]) .ne. chksum) call abort
contains
  subroutine foo
    a = [a, e]
  end subroutine
end

Note that 'foo' is for diagnostic purposes - the code is separated nicely.

Cheers

Paul