This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[Patch, fortran] PR37735 - Allocatable components in vectors of derived types cause ICE on assignment
- From: "Paul Richard Thomas" <paul dot richard dot thomas at gmail dot com>
- To: "Fortran List" <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 23 Nov 2008 15:51:02 +0100
- Subject: [Patch, fortran] PR37735 - Allocatable components in vectors of derived types cause ICE on assignment
The following testcase (which is now alloc_comp_assign_7.f90), would
ICE in the assignment to 'p' because structure_alloc_comps failed to
recognise that the array component 'r' is descriptorless. I have
absolutely no idea how Erik and I managed to miss this sort of derived
type in our testsuite case - I guess that there are just too many
possible combinations.
! { dg-do run }
!
! Test the fix for PR37735, in which gfc gagged in the assignement to
! 'p'. The array component 'r' caused an ICE.
!
! Contributed by Steven Winfield <saw44@cam.ac.uk>
!
module PrettyPix_module
implicit none
type Spline
real, allocatable, dimension(:) ::y2
end type Spline
type Path
type(Spline) :: r(3)
end type Path
type Scene
type(path) :: look_at_path
end type Scene
contains
subroutine scene_set_look_at_path(this,p)
type(scene), intent(inout) :: this
type(path), intent(in) :: p
this%look_at_path = p
end subroutine scene_set_look_at_path
end module PrettyPix_module
use PrettyPix_module
implicit none
integer :: i
real :: x(3) = [1.0, 2.0, 3.0]
type(scene) :: this
type(path) :: p
p = path ([spline([x(1)]),spline([x(2)]),spline([x(3)])])
call scene_set_look_at_path(this,p)
do i = 1, 3
if (this%look_at_path%r(i)%y2(1) .ne. x(i)) call abort
end do
end
! { dg-final { cleanup-modules "PrettyPix_module" } }
I would have applied the fix as 'obvious' were we not in regression
only mode. I think that this ice-on-invalid is sufficiently serious
that it should be fixed right away on trunk and 4.3.
Bootstrapped and regtested on FC9/x86_i64
OK for trunk and 4.3?
Paul
2008-11-08 Paul Thomas <pault@gcc.gnu.org>
PR fortran/37735
* trans-array.c (structure_alloc_comps): Do not duplicate the
descriptor if this is a descriptorless array!
2008-11-08 Paul Thomas <pault@gcc.gnu.org>
PR fortran/37735
* gfortran.dg/alloc_comp_assign_7.f90: New test.
Index: gcc/fortran/trans-array.c
===================================================================
--- gcc/fortran/trans-array.c (revision 142033)
+++ gcc/fortran/trans-array.c (working copy)
@@ -5543,10 +5543,12 @@
if (purpose == COPY_ALLOC_COMP)
{
- tmp = gfc_duplicate_allocatable (dest, decl, TREE_TYPE(decl), rank);
- gfc_add_expr_to_block (&fnblock, tmp);
-
- tmp = build_fold_indirect_ref (gfc_conv_descriptor_data_get (dest));
+ if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (dest)))
+ {
+ tmp = gfc_duplicate_allocatable (dest, decl, TREE_TYPE(decl), rank);
+ gfc_add_expr_to_block (&fnblock, tmp);
+ }
+ tmp = build_fold_indirect_ref (gfc_conv_array_data (dest));
dref = gfc_build_array_ref (tmp, index, NULL);
tmp = structure_alloc_comps (der_type, vref, dref, rank, purpose);
}