Re: [Patch, Fortran, F03] PR 40996: Allocatable Scalars

[Steve Kargl <sgk at troutmask dot apl dot washington dot edu>]

On Mon, Aug 31, 2009 at 01:05:38AM +0200, Janus Weil wrote:
> >>> What is still missing is a check if the type in the
> >>> ALLOCATE stmt is compatible with the type of the allocate-object (i.e.
> >>> C624, see my test case).
> >>>
> >>
> >> Which type? ?For the intrinsic types, the checking of compatibility
> >> was in my original type.
> >
> > Yeah, sure. This is about derived types, where you have two
> > possibilities AFAICS:
> > 1) If the object which is being allocated was declared with TYPE, the
> > ALLOCATE statement must have the same type (or omit it).
> > 2) If the object which was declared with CLASS, the ALLOCATE statement
> > may have any type which is a descendant of the original type.
> >
> > Btw: Do we have a function which checks if one type is an extension
> > (direct or indirect) of another, or do I have to invent this?
> 
> Ok, I have implemented this now (updated patch attached).
> 
> Btw, Steve: I'm wondering about your Fortran Standard references in
> gfc_match_allocate. What you labeled as C626 seems to be C624 in the
> version of the standard that I am looking at
> (http://www.j3-fortran.org/doc/year/04/04-007.pdf). Are you looking at
> a different version?
> 

Janus, 

The patch looks ok to me.  Paul or tobias may have a comment,
so you may want to give them a day or two to respond.

Here's a few rather minor comments.  In that the comments are
minor, feel free to ignore them.


Index: gcc/fortran/symbol.c
===================================================================
--- gcc/fortran/symbol.c	(revision 151200)
+++ gcc/fortran/symbol.c	(working copy)
@@ -4534,6 +4534,33 @@ gfc_get_derived_super_type (gfc_symbol* 
 }
 
 
+/* Check if two typespecs are compatible:
+   If ts1 is nonpolymorphic, ts2 must be the same type.
+   If ts1 is polymorphic (CLASS), ts2 must be an extension of ts1.
+   */
+
+int

In looking at the function and how it's used.  I'll suggest that
this should be bool.

+gfc_type_compatible (gfc_typespec *ts1, gfc_typespec *ts2)
+{
+  if (ts1->type == BT_DERIVED && ts2->type == BT_DERIVED)
+    {
+      gfc_symbol *t0,*t;

Space after the comma.

+      if (ts1->is_class)
+	{
+	  t0 = ts1->u.derived;
+	  t = ts2->u.derived;
+	  while (t0 != t && t->attr.extension)
+	    t = t->components->ts.u.derived;
+	  return (t0 == t);
+	}
+      else
+	return (ts1->u.derived == ts2->u.derived);
+    }
+  else
+    return (ts1->type == ts2->type);
+}
+
+
 /* General worker function to find either a type-bound procedure or a
    type-bound user operator.  */
 
Index: gcc/fortran/gfortran.h
===================================================================
--- gcc/fortran/gfortran.h	(revision 151200)
+++ gcc/fortran/gfortran.h	(working copy)
@@ -2469,6 +2469,7 @@ gfc_gsymbol *gfc_find_gsymbol (gfc_gsymb
 
 gfc_typebound_proc* gfc_get_typebound_proc (void);
 gfc_symbol* gfc_get_derived_super_type (gfc_symbol*);
+int gfc_type_compatible (gfc_typespec *, gfc_typespec *);

Change to bool if you agree with my comment above.

 gfc_symtree* gfc_find_typebound_proc (gfc_symbol*, gfc_try*,
 				      const char*, bool, locus*);
 gfc_symtree* gfc_find_typebound_user_op (gfc_symbol*, gfc_try*,
Index: gcc/fortran/match.c
===================================================================
--- gcc/fortran/match.c	(revision 151200)
+++ gcc/fortran/match.c	(working copy)
@@ -2221,21 +2221,22 @@ gfc_free_alloc_list (gfc_alloc *p)
 }
 
 
-/* Match a Fortran 2003 intrinsic-type-spec.  This is a stripped
+/* Match a Fortran 2003 allocate type-spec.  This is a stripped

I think that you can drop 'allocate' here.  We have implemented
R401.  I did the intrinsic-type-spec apart, and you (and pault?)
did the derived-type-spec part without the optional ( type-param-spec-list ) 
portion in R455.   If fact, we can probably rename match_allocate_typespec
to gfc_match_type_spec and what is currently named gfc_match_type_spec
should be renamed to gfc_match_declaration_type_spec (See R501).
Note the renaming and parsing of ( type-param-spec-list ) is not a
showstopper that prevents you from committing the current patch.

    down version of gfc_match_type_spec() from decl.c.  It only includes
    the intrinsic types from the Fortran 2003 standard.  Thus, neither
    BYTE nor forms like REAL*4 are allowed.  Additionally, the implicit_flag
-   is not needed, so it was removed.  The handling of derived types has
-   been removed and no notion of the gfc_matching_function state
-   is needed.  In short, this functions matches only standard conforming
-   intrinsic-type-spec (R403).  */
+   is not needed, so it was removed.  Derived types are identified by
+   their name alone.  */
 
-- 
Steve