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
