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] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |