Re: [Patch, Fortran] F2003: More ASSOCIATE stuff

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

 Daniel Kraft wrote:
> here's another ASSOCIATE patch.  It shifts handling of the variables 
> and their initialization to the trans-* phase.  This fixes the 
> problems with array boundaries and implements association to 
> variables.  I think most of the useful stuff should work with this now.
Awesome!

> What does not work [...] is association to strings. [...]
> parsing of component references if you associate a variable to a 
> derived-type value
(The latter is a rather important case, looking at my Fortran 2003 books 
...)

You can add to the list: Polymorphic types. The following example is 
rejected with:

associate ( one => a, two => b)
                    1
Error: CLASS variable 'one' at (1) must be dummy, allocatable or pointer

!----------------------------
type t
end type t

type, extends(t) :: t2
end type t2

class(t), allocatable :: a, b
allocate( t :: a)
allocate( t2 :: b)

associate ( one => a, two => b)
  select type(two)
    type is (t)
      stop 'ERROR'
    type is (t2)
      print *, 'OK', two
    class default
      stop 'ERROR'
  end select
  select type(one)
    type is (t2)
      stop 'ERROR'
    type is (t)
      print *, 'OK', one
    class default
      stop 'ERROR'
  end select
end associate
end
!----------------------------


I also would expect an error for:

subroutine test(x)
  integer, intent(in) :: x
  associate ( y => x)
    y = 7
  end associate
end subroutine test

due to the INTENT(IN).


> I saw two failures, namely array_memcpy_3.f90 and bind_c_dts_3.f90.  
> Is this currently broken?

I saw them as well - though the array_memcpy_3.f90 looked a bit spurious 
- especially, I got either a MEMREF or memcopy. With bind_c_dts_3.f90, I 
wonder whether this is due to my recent DT bugfix. I thought I fixed 
that before the committal - can you try to find out why you see this? 
Maybe do an "svn up" in gcc/testsuite/gfortran.dg to make sure your file 
is up to date.

Looking at http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg01641.html 
or at http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg01640.html I also 
see the array_memcpy_3.f90 failure, but no bind_c_dts_3.f90 failure. 
Thus, I think this failure does not prevent a committal.

> Ok for trunk when this is figured out?

OK, but I have one nit:

+	  gfc_error ("'%s' at %L associated to %s can not"
+		     " be used in a variable definition context",
+		     sym->name,&sym->declared_at,
+		     (target->expr_type == EXPR_VARIABLE
+		      ? "vector-indexed target" : "expression"));


Can you split this into two gfc_errors? I think we make the live for the 
translators much easier if we do not use %s + a string.

More general remark, not preventing the committal:

+  ASSOCIATE (a =>  5,&  ! { dg-error "variable definition context" }
+             b =>  arr((/ 1, 3 /))) ! { dg-error "variable definition context" }
+    a = 4
+    b = 7


At least for long ASSOCIATE blocks, I think it would be more helpful to 
have the error in the "a = 4" line and not in the "a => 5" line.

Tobias

PS: I have not yet thought about the other points you have raised in 
your email.