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

[Janus Weil <janus at gcc dot gnu dot org>]

Hi Paul,


> I'll try to look at this and the gimplifier problem this afternoon.

that would be great.


> I have attached a provisional patch to allow derived type specification
> in allocate statements. ?Perhaps you would like to take it over and
> incorporate it in your patch?

Sure :)


> It does regtest OK but it needs
> possible error conditions checking out; for example
>
> ?allocate(non-existent-symbol :: x(2))
> ? ? ? ? ? ? ? ? ? 1
> Error: Allocate-object at (1) is not a nonprocedure pointer or an
> allocatable variable
>
> Which is OK from the perspective of it producing an error but might
> perplex the uninitiated:-)

I extended your patch a bit so that it gives a better error message
for this example. It also rejects abstract types in the ALLOCATE
statement. 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).

Cheers,
Janus



> On Sat, Aug 29, 2009 at 8:15 PM, Janus Weil<janus@gcc.gnu.org> wrote:
>> Hi all,
>>
>> I have started to implement allocatable scalars. Attached you find two
>> patches (each with a corresponding test case):
>>
>> ?* The first one contains everything needed for simple allocatable
>> scalar variables to work. This is rather complete, I think, and should
>> be ready for check-in AFAICS.
>>
>> ?* The second patch is the continuation to allocatable scalar
>> components. This is not quite ready yet and still gives gimplification
>> errors for ALLOCATE and DEALLOCATE statements. At the moment I fail to
>> see what goes wrong where, but my guess is that the problem lies in
>> gfc_trans_allocate or gfc_allocate_with_status.
>>
>> So, what I would like to know is: Is the first patch ok, or are there
>> any problems that I overlooked? And if yes: Should I commit it
>> already, or rather wait until the second part is complete, too? And
>> for the second part: Does anyone have an idea where the gimplification
>> errors come from and how to get rid of them?
>>
>> Side note: The test case finalize_9.f03 does not have anything to do
>> with finalization. I propose to "svn mv" it to
>> "allocatable_scalars_..."
>>
>> Btw: The first patch is regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>>
>> Cheers,
>> Janus
>>
>>
>> 2009-08-29 ?Janus Weil ?<janus@gcc.gnu.org>
>>
>> ? ? ? ?PR fortran/40996
>> ? ? ? ?* check.c (gfc_check_allocated): Implement allocatable scalars.
>> ? ? ? ?* resolve.c (resolve_allocate_expr,resolve_fl_var_and_proc): Ditto.
>> ? ? ? ?* trans-intrinsic.c (gfc_conv_allocated): Ditto.
>>
>> 2009-08-29 ?Janus Weil ?<janus@gcc.gnu.org>
>>
>> ? ? ? ?PR fortran/40996
>> ? ? ? ?* gfortran.dg/allocatable_scalars_1.f90: New.
>> ? ? ? ?* gfortran.dg/proc_ptr_comp_pass_4.f90: Modified.
>> ? ? ? ?* gfortran.dg/finalize_9.f03: Modified.
>>
>
>
>
> --
> The knack of flying is learning how to throw yourself at the ground and miss.
> ? ? ? --Hitchhikers Guide to the Galaxy
>

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
    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.  */
 
 static match
-match_intrinsic_typespec (gfc_typespec *ts)
+match_allocate_typespec (gfc_typespec *ts)
 {
   match m;
+  gfc_symbol *derived;
+  locus old_locus;
 
   gfc_clear_ts (ts);
+  old_locus = gfc_current_locus;
 
   if (gfc_match ("integer") == MATCH_YES)
     {
@@ -2278,7 +2279,43 @@ match_intrinsic_typespec (gfc_typespec *
       goto kind_selector;
     }
 
-  /* If an intrinsic type is not matched, simply return MATCH_NO.  */ 
+  if (gfc_match_symbol (&derived, 1) == MATCH_YES)
+    {
+      if (derived->attr.flavor == FL_DERIVED)
+	{
+	  old_locus = gfc_current_locus;
+	  if (gfc_match (" :: ") != MATCH_YES)
+	    return MATCH_ERROR;
+	  gfc_current_locus = old_locus;
+	  ts->type = BT_DERIVED;
+	  ts->u.derived = derived;
+	  /* C401.  */
+	  if (derived->attr.abstract)
+	    {
+	      gfc_error ("Derived type '%s' at %L may not be ABSTRACT",
+			 derived->name, &old_locus);
+	      return MATCH_ERROR;
+	    }
+	  return MATCH_YES;
+	}
+      else
+	{
+	  if (gfc_match (" :: ") == MATCH_YES)
+	    {
+	      /* C476.  */
+	      gfc_error ("'%s' at %L is not an accessible derived type",
+			 derived->name, &old_locus);
+	      return MATCH_ERROR;
+	    }
+	  else
+	    {
+	      gfc_current_locus = old_locus;
+	      return MATCH_NO;
+	    }
+	}
+    }
+
+  /* If a type is not matched, simply return MATCH_NO.  */ 
   return MATCH_NO;
 
 kind_selector:
@@ -2381,7 +2418,7 @@ gfc_match_allocate (void)
 
   /* Match an optional intrinsic-type-spec.  */
   old_locus = gfc_current_locus;
-  m = match_intrinsic_typespec (&ts);
+  m = match_allocate_typespec (&ts);
   if (m == MATCH_ERROR)
     goto cleanup;
   else if (m == MATCH_NO)

Attachment: match_allocate.f90
Description: Binary data