[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
Sat Dec 15 20:47:00 GMT 2012
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?
More information about the Gcc-bugs
mailing list