Re: [Patch, Fortran] First ASSOCIATE patch and some questions / RFCs

[Tobias Burnus <burnus at net-b dot de>]

On 06/06/2010 07:47 PM, Daniel Kraft wrote:
> attached is my first patch on the way of implementing the ASSOCIATE
> construct.  [...]
>
> The patch was regression-tested on GNU/Linux-x86-32.
> array_constructor_11.f90 failed with -O3 -g, but I don't see how this
> could be related to my patch...  Does anyone else see this?  If so, ok
> for trunk?

+      /* The target is a variable (and may be used as lvalue) if it's an
+	 EXPR_VARIABLE and does not have vector-subscripts.  In addition,
+	 it must not be coindexed.  */
+      newAssoc->variable = (newAssoc->target->expr_type == EXPR_VARIABLE
+			    && !gfc_is_coindexed (newAssoc->target)
+			    && !gfc_has_vector_subscript (newAssoc->target));


I think you got the coarray check wrong. At least I read C803 such that
coarrays are not allowed at all - contrary to vector-subscripted
variables, which are only allowed in a variable-definition context (C801).

Thus, I expect a gfc_error for:
  C803 (R805) variable shall not be a coindexed object.

(Note: C804 closes a loop-hole which would allow it as "expr": "C804
(R805) expr shall not be a variable.")


-  /* Check for the IF, DO, SELECT, WHERE, FORALL, CRITICAL, and BLOCK
+  /* Check for the IF, DO, SELECT, WHERE, FORALL, BLOCK and ASSOCIATE
      statements, which might begin with a block label.  The match functions for

What happened to "CRITICAL" in the comment?

+  my_ns = gfc_build_block_ns (gfc_current_ns); [...]

+  new_st.ext.block.ns = my_ns;
[...]

+	if (gfc_get_sym_tree (a->name, NULL, &a->st, false))
+	  /* XXX: Hopefully.  */
+	  gcc_unreachable ();


I think the unreachable is fine. You create a new namespace and thus
there should be no non-zero return value (= ambiguious symbol) as there
should be no other symbols in this namespace.


@@ -3543,7 +3638,6 @@ parse_executable (gfc_statement st)
 	  case ST_CRITICAL:
-	  case ST_BLOCK:
 	  case ST_FORALL:
 	  case ST_WHERE:
 	  case ST_SELECT_CASE:
@@ -3573,6 +3667,10 @@ parse_executable (gfc_statement st)
+	case ST_ASSOCIATE:
+	  parse_associate ();
+	  break;
+


Why don't you need ST_BLOCK anymore?


I miss a test case for the following two errors messages:

associate (x => 5)
  integer :: u ! { dg-error "Unexpected data declaration statement" }
  x =  34 ! { dg-error "can't appear in a variable definition context" }
end associate
end


Otherwise, the patch looks good.

Tobias

PS: I will try to answer the "variable definition context" question later.

PPS: The following program gives the expected not-yet-implemented error
but then an ICE (segfault). Valgrind shows:

==1273== Invalid read of size 8
==1273==    at 0x53E528: gfc_find_sym_tree (symbol.c:2567)
==1273==    by 0x53E8DE: gfc_get_ha_sym_tree (symbol.c:2736)
==1273==    by 0x4FC3AA: gfc_match_sym_tree (match.c:678)
and
==1273== Invalid write of size 8
==1273==    at 0x4BA6C9: gfc_insert_bbt (bbt.c:137)
==1273==    by 0x53E138: gfc_new_symtree (symbol.c:2362)


type t
  real :: ev
end type t
type t2
  type(t) :: c
end type t2
type(t2) :: ax(2,2)
integer :: i , n
i = 1
n = 2
ax(1,1)%c%ev = 1
ax(2,1)%c%ev = 2
ax(1,2)%c%ev = 3
ax(2,2)%c%ev = 4
associate ( array => ax(i,:)%c )
   array(n)%ev = array(n-1)%ev
end associate
end