[Patch, Fortran] PR55763 - improve init-data checks for pointers

Mikael Morin mikael.morin@sfr.fr
Mon Jan 7 17:36:00 GMT 2013


Hello,

Le 04/01/2013 13:51, Tobias Burnus a écrit :
> diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
> index 2610784..146154e 100644
> --- a/gcc/fortran/expr.c
> +++ b/gcc/fortran/expr.c
> @@ -3291,22 +3291,21 @@ gfc_check_assign (gfc_expr *lvalue, gfc_expr *rvalue, int conform)
>  gfc_try
>  gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr *rvalue)
>  {
> -  symbol_attribute attr;
> +  symbol_attribute attr, lhs_attr;
>    gfc_ref *ref;
>    bool is_pure, is_implicit_pure, rank_remap;
>    int proc_pointer;
>
> -  if (lvalue->symtree->n.sym->ts.type == BT_UNKNOWN
> -      && !lvalue->symtree->n.sym->attr.proc_pointer)
> +  lhs_attr = gfc_expr_attr (lvalue);
> +  if (lvalue->ts.type == BT_UNKNOWN && !lhs_attr.proc_pointer)
>      {
>        gfc_error ("Pointer assignment target is not a POINTER at %L",
>  		 &lvalue->where);
>        return FAILURE;
>      }
>
> -  if (lvalue->symtree->n.sym->attr.flavor == FL_PROCEDURE
> -      && lvalue->symtree->n.sym->attr.use_assoc
> -      && !lvalue->symtree->n.sym->attr.proc_pointer)
> +  if (lhs_attr.flavor == FL_PROCEDURE && lvalue->symtree->n.sym->attr.use_assoc
Should it be lhs_attr.use_assoc (for consistency)?


> The patch has a downside: One gets some messages twice or trice: Once
> for resolving the type declaration ("type t") and then for resolving the
> default initialization via
> gfc_traverse_ns (ns, resolve_values);
That's a bit annoying, but better have diagnostics twice than not at all.

>
> Currently, that's unavoidable as one cannot trivially distinguish
> between a user-supplied "sym->value" and the default constructor. If you
> think that this is a problem, one can change it, e.g. by setting a
> sym->attr.value_is_default_init.
Or we can keep sym->value cleared until translation stage where the 
(default) initialization is picked directly from the type.
Anyway....

>
>
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?
....OK (even in its current state).

Mikael



More information about the Gcc-patches mailing list