Hello,
Le 08/04/2025 à 15:29, Andre Vehreschild a écrit :
Hi all,
while working at teams stuff I encountered some issue with the ASSOCIATE
statement:
1. First of all: It does not open its namespace as it is expected to. I.e. the
associate-name (referring to the term as used in F2018 11.1.3.1 R1104) is put
into the parent namespace/scope and not into its own (overwriting values
possibly).
Yes, there are bugs unfortunately. I thought ASSOCIATE were creating
BLOCK constructs under the hood, but I may well be wrong.
2. Doing
associate(me => this_image(), num => num_images(), foo = MOD(me + 43, num))
produces a very unexpected value of foo. If it is computed at all! I got a
SigFPE for a long time, before I figured that the me and num in the expression
of foo are not the ones from the associate, but are not initialized variable of
the parent scope. I therefore worked to resolve this and found one test
(associate_1.f03), that check exactly this (IMO wrong) behavior. Testing with
Intel's latest Fortran compiler, the test fails, too. Intel also allows using
former associate-names in the later expr.
Not sure I understand; the test associate_1.f03 has:
a = -2.0
b = 3.0
...
ASSOCIATE (a => 1 * b, b => 1 * a, x => 1, y => 2)
IF (ABS (a - 3.0) > 1.0e-3 .OR. ABS (b + 2.0) > 1.0e-3) STOP 9
So A has the value of B from the parent scope, and B has the value of A
from the parent scope. Are you saying this is wrong?
Therefore my question: Why is this implemented that way? When I read F2018
19.6.7 correctly, then it only means that recursive references are not allowed,
i.e. associate( v => f(v) ) or the like. But referencing an associate-name in a
latter expr is fine, because that is not recursive.
Any comments, insight or pointers to why a "defined" associate-name must not
occur in an associate expr, but may occur in an associate immediately
following, are very much appreciated!
I think that behaviour is correct. While the cross-references don't
seem to be explicitly prohibited, the ASSOCIATE construct execution is
defined as follows (f2023, 11.1.3.2):
Execution of an ASSOCIATE construct causes evaluation of every expression
within every selector that is a
variable designator and evaluation of every other selector, followed by
execution of its block. During execution of
that block each associate name identifies an entity which is associated
(19.5.1.6) with the corresponding selector.
This doesn't specify any evaluation order of selectors, and tells that
the names are associated with the selectors during the execution of the
block, but doesn't say anything about the names during the evaluation of
selectors. My conclusion is that the names are not defined/associated
during the evaluation of selectors.
Hope it helps...
Mikael
