This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]