[Fortran,Patch] PR 45170 - Implement parsing/resolution of character deferred type parameter
Daniel Kraft
d@domob.eu
Tue Nov 2 10:43:00 GMT 2010
Hi Tobias,
Tobias Burnus wrote:
> *PING*
>
> I updated the patch by removing the match_type_spec part and the
> gfortran.dg/allocate_derived_1.f90 change as those changes were applied
> as part of Steve's patch at
> http://gcc.gnu.org/ml/fortran/2010-10/msg00285.html
>
> Otherwise, the patch is unchanged. Rediff attached. I have rebuild the
> patch and will regtest it, but I do not expect any failures.
>
> OK for the trunk?
Yes. Two comments:
@@ -701,6 +712,7 @@ match_char_length (gfc_expr **expr)
{
int length;
match m;
+ bool deferred = false;
m = gfc_match_char ('*');
if (m != MATCH_YES)
@@ -722,7 +734,7 @@ match_char_length (gfc_expr **expr)
if (gfc_match_char ('(') == MATCH_NO)
goto syntax;
- m = char_len_param_value (expr);
+ m = char_len_param_value (expr, &deferred);
if (m != MATCH_YES && gfc_matching_function)
{
gfc_undo_symbols ();
It seems that in match_char_length (unlike gfc_match_char_spec) you
simply ignore the value of deferred... I wonder whether that can be
"correct" -- maybe we want a check (or even assert?) that deferred is
false if it does not need to be handled?
+ else if (sym->ts.deferred)
+ gfc_fatal_error ("Deferred type parameter not yet supported");
Do we need both this check and the one in resolve.c? It does not hurt,
though... Just curious.
Thanks for the patch (to Steve and you)!
Daniel
More information about the Fortran
mailing list