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] PR39519 - [4.4 Regression] bad assignment to type with allocatable component


This one is embarrassing but the fix is obvious and safe.  The
detection of pointer or allocatable components was mutually excluding
that the derived type could gain the attribute that it have the other.

Unfortunately, in spite of the identification of this as being a
regression, it was built into Erik and my original patch:-(
http://gcc.gnu.org/viewcvs/trunk/gcc/fortran/parse.c?r1=117558&r2=117557&pathrev=11755

What shall I do?  It is a major fault and, as I say, the patch is
safe.  However, it is not a regression, in fact.

Bootstraps and regtests on FC9/x86_64

Paul

2009-03-22  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/38765
	* parse.c.c (parse_derived): Do not break on finding pointer or
	allocatable components.

2009-03-22  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/38765
	* gfortran.dg/alloc_comp_assign_9.f90: New test.
Index: gcc/fortran/parse.c
===================================================================
--- gcc/fortran/parse.c	(revision 144448)
+++ gcc/fortran/parse.c	(working copy)
@@ -1980,7 +1980,6 @@
 	  || (c->ts.type == BT_DERIVED && c->ts.derived->attr.alloc_comp))
 	{
 	  sym->attr.alloc_comp = 1;
-	  break;
 	}
 
       /* Look for pointer components.  */
@@ -1988,7 +1987,6 @@
 	  || (c->ts.type == BT_DERIVED && c->ts.derived->attr.pointer_comp))
 	{
 	  sym->attr.pointer_comp = 1;
-	  break;
 	}
 
       /* Look for private components.  */
Index: gcc/testsuite/gfortran.dg/alloc_comp_assign_9.f90
===================================================================
--- gcc/testsuite/gfortran.dg/alloc_comp_assign_9.f90	(revision 0)
+++ gcc/testsuite/gfortran.dg/alloc_comp_assign_9.f90	(revision 0)
@@ -0,0 +1,20 @@
+! { dg-do run }
+! Test the fix for PR39519, where the presence of the pointer
+! as the first component was preventing the second from passing
+! the "alloc_comp" attribute to the derived type.
+!
+! Contributed by Gilbert Scott <gilbert.scott@easynet.co.uk>
+!
+PROGRAM X
+  TYPE T
+    INTEGER, POINTER :: P
+    INTEGER, ALLOCATABLE :: A(:)
+  END TYPE T
+  TYPE(T) :: T1,T2
+  ALLOCATE ( T1%A(1) )
+  ALLOCATE ( T2%A(1) )
+  T1%A = 23
+  T2 = T1
+  T1%A = 42
+  if (T2%A(1) .NE. 23) CALL ABORT
+END PROGRAM X

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