[Bug fortran/55072] [4.6/4.7/4.8 Regression] Missing internal_pack leads to wrong code with derived type

["janus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #15 from janus at gcc dot gnu.org 2012-12-15 20:47:00 UTC ---
(In reply to comment #11)
> FAIL: gfortran.dg/assumed_type_2.f90  -O0   scan-tree-dump-times original
> "sub_array_assumed \\(D" 2
> FAIL: gfortran.dg/assumed_type_2.f90  -O0   scan-tree-dump-times original
> "sub_array_assumed \\(\\(struct t3.0:. .\\) array_t3_ptr.data\\);" 1


Here is a reduced test case for these two failure (which are apparently due to
a single underlying problem):


! { dg-do compile }
! { dg-options "-fdump-tree-original" }

implicit none
type :: t3
  integer :: c
end type t3

type(t3), pointer     :: array_t3_ptr(:,:)

call sub_array_assumed (array_t3_ptr)

contains

  subroutine sub_array_assumed (arg3)
     type(*), target :: arg3(*)
  end subroutine

end

! { dg-final { scan-tree-dump-times "sub_array_assumed \\(D" 0 "original" } }
! { dg-final { scan-tree-dump-times "sub_array_assumed \\(\\(struct t3.0:. .\\)
array_t3_ptr.data\\);" 1 "original" } }
! { dg-final { cleanup-tree-dump "original" } }


The point is this: Without the patch, the subroutine call is translated to:

  sub_array_assumed ((struct t3[0:] *) array_t3_ptr.data);

while, with the patch, it becomes:

    D.1892 = _gfortran_internal_pack (&array_t3_ptr);
    sub_array_assumed (D.1892);

i.e., the argument is packed.


Question is: Is the packing needed here? I would guess that it isn't. And if
not, how do we best avoid it?