Patchwork [Fortran] PR52029/52013 - small OOP fixes (pure _copy, CAF fix)

login
register
mail settings
Submitter Tobias Burnus
Date Jan. 30, 2012, 8:54 p.m.
Message ID <4F27038E.5090307@net-b.de>
Download mbox | patch
Permalink /patch/138635/
State New
Headers show

Comments

Tobias Burnus - Jan. 30, 2012, 8:54 p.m.
First, I am looking for someone to review my patch at 
http://gcc.gnu.org/ml/fortran/2012-01/msg00241.html

This patch contains two patches:

a) Marking the polymorphic _copy function as pure. First, it helps with 
code generation as the function is actually pure. Secondly, if one 
defines the derived type in a PURE function, one currently gets an error 
as the impure function _copy is called.

b) We need to build a different class container type for coarrays - the 
attached test case is an example why (missing diagnosis as the container 
didn't have the coarray attribute). At the same time, I fixes the hash 
function criterion. Since the polymorphic array patch, one some long 
module + type names were cropped instead of triggering the hash 
mechanism, increasing the chance for name collision.

Build and regtested on x86-64-linux.
OK for the trunk?

Tobias
Paul Richard Thomas - Jan. 31, 2012, 12:44 p.m.
Dear Tobias,

OK for trunk on both.

Thanks

Paul

On Mon, Jan 30, 2012 at 9:54 PM, Tobias Burnus <burnus@net-b.de> wrote:
> First, I am looking for someone to review my patch at
> http://gcc.gnu.org/ml/fortran/2012-01/msg00241.html
>
> This patch contains two patches:
>
> a) Marking the polymorphic _copy function as pure. First, it helps with code
> generation as the function is actually pure. Secondly, if one defines the
> derived type in a PURE function, one currently gets an error as the impure
> function _copy is called.
>
> b) We need to build a different class container type for coarrays - the
> attached test case is an example why (missing diagnosis as the container
> didn't have the coarray attribute). At the same time, I fixes the hash
> function criterion. Since the polymorphic array patch, one some long module
> + type names were cropped instead of triggering the hash mechanism,
> increasing the chance for name collision.
>
> Build and regtested on x86-64-linux.
> OK for the trunk?
>
> Tobias

Patch

2012-01-30  Tobias Burnus  <burnus@net-b.de>

	PR fortran/52029
	* class.c (gfc_find_derived_vtab): Mark _copy function as pure.

2012-01-30  Tobias Burnus  <burnus@net-b.de>

	PR fortran/52029
	* gfortran.dg/class_49.f90: New.

Index: gcc/fortran/class.c
===================================================================
--- gcc/fortran/class.c	(Revision 183737)
+++ gcc/fortran/class.c	(Arbeitskopie)
@@ -715,6 +717,7 @@  gfc_find_derived_vtab (gfc_symbol *derived)
 		  sub_ns->proc_name = copy;
 		  copy->attr.flavor = FL_PROCEDURE;
 		  copy->attr.subroutine = 1;
+		  copy->attr.pure = 1;
 		  copy->attr.if_source = IFSRC_DECL;
 		  /* This is elemental so that arrays are automatically
 		     treated correctly by the scalarizer.  */
Index: gcc/testsuite/gfortran.dg/class_49.f90
===================================================================
--- gcc/testsuite/gfortran.dg/class_49.f90	(Revision 0)
+++ gcc/testsuite/gfortran.dg/class_49.f90	(Arbeitskopie)
@@ -0,0 +1,11 @@ 
+! { dg-do compile }
+!
+! PR fortran/52029
+!
+
+elemental subroutine foo()
+  type t
+  end type t
+  class(t), allocatable :: x
+  if (allocated(x)) i = 5
+end