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:
> Association of names to variables (currently only expressions).  I
> think that my original idea of replacing each occurrence directly in
> the parser with the corresponding gfc_expr does not work, because it
> will do the wrong thing if the selector expression changes, as in
> these two cases:
>
> INTEGER, POINTER :: ptr
> ptr => something
> ASSOCIATE (x => ptr)
>   ptr => something else
>   ! x should still refer to something
> END ASSOCIATE

I think that's not the case: "x" is just an associated name for "ptr"
and not a pointer, which then points to the target of "ptr" (i.e.
"something" in your example). That's also what I get with ifort.

> INTEGER :: n
> REAL :: array(10)
> n = 2
> ASSOCIATE (arr => array(n : n+2)
>   n = 5
>   ! arr is still array(2 : 4)
> END ASSOCIATE

Here, the standard explicitly mentions (in an informal note) that that
the bounds have to be evaluated first, i.e. arr is - as you wrote -
still array(2:4):

"NOTE 16.11  The association between the associate name and a data
object is established prior to execution of the block and is not aected
by subsequent changes to variables that were used in subscripts or
substring ranges in the selector."

Thus, it could make sense to evaluate the bonds before and save them in
a local integer variable but still do the
associate-name--to--data-object replacement - but using the local
integer. That way one reduces the pointer variables one presents to the
middle end and gets closer to the semantics of the Fortran standard.

> So instead we need another strategy; possibly using a BLOCK local
> pointer that it pointed to the selector.

That would be an alternative, though I wonder whether just having a
local bounds variable would be better - especially in the case of
compile-time constants, the resulting code could be cleaner.

> Does this provoke problems, when the selector is not TARGET or the like?
Well, TARGET is a Fortran concept and not a GIMPLE concept; I think one
has to think carefully which item to mark as TYPE_QUAL_RESTRICT and
which not - and of course, the more TYPE_QUAL_RESTRICT the better. Best
ask a middle-end person when it is clear how you use it.

> Association to array expressions.  The problem here is that for
> something like:
>
> INTEGER :: array(10)
> ASSOCIATE (doubled => 2 * array)
>   PRINT *, doubled(2)
> END ASSOCIATE
>
> During parsing, the expression "2 * array" seems not to have its rank
> defined yet; this is only done at resolution stage.  However, when
> parsing doubled(2), the compiler already needs to know that doubled is
> an array!  Any ideas what we could do here?

I do not have an ad-hoc idea; I think one has to defer this to
resolution time as I do not see how you want to handle
  doubled => 2 * array(f())
where "f" is a generic procedure which either returns a scalar integer
(-> doubled is a scalar) or it returns an array (-> doubled is an array
of rank).

> Otherwise, I think that with the ability of BLOCK to declare
> "dynamically sized" arrays (like VLA's in C)
Called in Fortran 90+: Automatic arrays.

I plan to review the patch later today.

Tobias