Many to one assignments are prohibited in a FORALL. The restriction
is in 7.5.4.4 in the F95 standard. It's a text restriction, as opposed
to a constraint, because it can't always be checked at compile time.
Although your example could be checked things like
FORALL (i=1:10) A(INDEX(I)) = B(I)
can't generally be checked at compile time.
The FORALL does allow many-to-one stores in multiple statements.
FORALL (I = 1:10)
A(I) = A(I+L) + 1.0
A(I+K) = A(I+J) + 2.0
END FORALL
is well defined. The first assignment is executed 10 times, then the
second is executed 10 times.
Dick Hendrickson
Niki Reid wrote:
>
> Hi all.
>
> I have a query regarding the FORALL construct, and specifically
> non-determinism.
>
> The previous FORALL thread briefly touched on many-to-one
> assignments, but never went far enough to answer my query.
>
> For example, given:
>
> INTEGER A(2), B(2)
> ...
> FORALL (i=1:2, j=1:2)
> A(i) = B(j)
> END FORALL
>
> According to the standard the active index set is:
> { (i=1, j=1), (i=1, j=2), (i=2, j=1), (i=2, j=2) }, and the
> body statement(s) must be executed for all indexes in the index
> set.
>
> This means that the above FORALL construct is equivalent to the
> parallel (simultaneous) assignments:
> A(1) = B(1)
> A(1) = B(2)
> A(2) = B(1)
> A(2) = B(2)
>
> I know that in other places in the standard, such as array
> assignment, non-determinism is prohibited, but this is not an
> array assignment: each assignment in the given example is
> treated as though it were scalar.
>
> The overall result, though, is a non-deterministic FORALL
> construct, which I can't find prohibited in the standard.
>
> Am I missing something, or it this as intended?
>
> All replies gratefully received!
>
> Niki
|