This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [Patch, Fortran, F03] PR 40996: Allocatable Scalars
- From: Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>
- To: Janus Weil <janus at gcc dot gnu dot org>
- Cc: gfortran <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 30 Aug 2009 10:22:23 +0200
- Subject: Re: [Patch, Fortran, F03] PR 40996: Allocatable Scalars
- References: <854832d40908291115r7aa83dcal2513b616c4553209@mail.gmail.com>
Janus,
I'll try to look at this and the gimplifier problem this afternoon. 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? 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:-)
Cheers
Paul
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 151199)
+++ gcc/fortran/match.c (working copy)
@@ -2221,21 +2221,22 @@
}
-/* 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,29 @@
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)
+ {
+ gfc_current_locus = old_locus;
+ ts->type = BT_DERIVED;
+ ts->u.derived = derived;
+ return MATCH_YES;
+
+ }
+ else 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 +2404,7 @@
/* 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)