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

[Mikael Morin]

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

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

[Tobias Burnus]

Early * ping*
http://gcc.gnu.org/ml/fortran/2013-01/msg00025.html


On January 4, 2013, Tobias Burnus wrote:

Fortran 2008 allows:
   integer :: pointer => init_data
and
  type t
 integer :: pointer => init_data
  end type t

The current check in gfc_check_assign_symbol was only called for 
former and for constructors, but not for the type definition. 
Additionally, BT_CLASS wasn't handled. I also improved the error 
location.




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);

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.



Build and regtested on x86-64-gnu-linux.
OK for the trunk?

Tobias

PS: For CLASS pointers, there will be an ICE if one tries to associate 
a variable to them; that's unchanged by this patch.