This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[Patch, fortran] PR33566 - fortran : wrong rank of derived type parameters array components
- From: "Paul Richard Thomas" <paul dot richard dot thomas at gmail dot com>
- To: "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>, "gcc-patches List" <gcc-patches at gcc dot gnu dot org>
- Date: Sat, 29 Sep 2007 11:38:04 +0200
- Subject: [Patch, fortran] PR33566 - fortran : wrong rank of derived type parameters array components
:ADDPATCH fortran:
This one is really annoying because I fixed the problem for use
associated derived type parameters just recently - I never even
thought to check that parameters in the same scope as the expression
worked OK. Anyway, this works by removing the check for use
association in the previous patch. I also let the simplifier do its
thing for full array references; otherwise, any array reference to a
derived type parameter is treated as a variable expression.
The testcase is the reporter's, with the addition of a second
previously failing expression.
Bootstrapped and regtested on x86_ia64/FC5 - OK for trunk?
Paul
2007-09-29 Paul Thomas <pault@gcc.gnu.org>
PR fortran/33566
* primary.c (gfc_match_rvalue): Make all expressions with array
references to structure parameters into variable expressions.
2007-09-29 Paul Thomas <pault@gcc.gnu.org>
PR fortran/33566
* gfortran.dg/derived_comp_array_ref_5.f90: New test.
--
The knack of flying is learning how to throw yourself at the ground and miss.
--Hitchhikers Guide to the Galaxy
Index: gcc/fortran/primary.c
===================================================================
*** gcc/fortran/primary.c (revision 128873)
--- gcc/fortran/primary.c (working copy)
*************** gfc_match_rvalue (gfc_expr **result)
*** 2148,2165 ****
if (sym->ts.is_c_interop || sym->ts.is_iso_c)
break;
! /* Variable array references to use associated derived type
! parameters cause all sorts of headaches in simplification.
! For this reason, we write the parameter to the module and
! treat them as variable references. */
! if (sym->value && sym->ts.type == BT_DERIVED
! && sym->attr.use_assoc && e->ref)
{
for (ref = e->ref; ref; ref = ref->next)
if (ref->type == REF_ARRAY)
break;
! if (ref == NULL)
break;
ref = e->ref;
--- 2148,2164 ----
if (sym->ts.is_c_interop || sym->ts.is_iso_c)
break;
! /* Variable array references to derived type parameters cause
! all sorts of headaches in simplification. Treating such
! expressions as variable works just fine for all array
! references. */
! if (sym->value && sym->ts.type == BT_DERIVED && e->ref)
{
for (ref = e->ref; ref; ref = ref->next)
if (ref->type == REF_ARRAY)
break;
! if (ref == NULL || ref->u.ar.type == AR_FULL)
break;
ref = e->ref;
Index: /svn/trunk/gcc/testsuite/gfortran.dg/derived_comp_array_ref_5.f90
===================================================================
*** /svn/trunk/gcc/testsuite/gfortran.dg/derived_comp_array_ref_5.f90 (revision 0)
--- /svn/trunk/gcc/testsuite/gfortran.dg/derived_comp_array_ref_5.f90 (revision 0)
***************
*** 0 ****
--- 1,36 ----
+ ! { dg-do compile }
+ ! Tests the fix for PR33566, in which the first variable array ref
+ ! to v1 would cause an incompatible ranks error and the second an ICE.
+ !
+ ! Contributed by Mikael Morin <mikael.morin@tele2.fr>
+ !
+ program test_vec
+
+ implicit none
+
+
+ integer :: i
+ real :: x
+
+ type vec3
+ real, dimension(3) :: coords
+ end type vec3
+
+ type(vec3),parameter :: v1 = vec3((/ 1.0, 2.0, 3.0 /))
+ type(vec3) :: v2
+
+ v2 = vec3((/ 1.0, 2.0, 3.0 /))
+
+
+ x = v1%coords(1)
+
+ do i=1,3
+ x = v1%coords(i) ! used to fail
+ x = v2%coords(i)
+ end do
+
+ i = 2
+
+ v2 = vec3 (v1%coords ((/i+1, i, i-1/))) ! also broken
+
+ end program test_vec