forums.silverfrost.com

[Kenneth_Smith]

Consider the use of the FORALL statement in the following code.

FTN95 accepts this a valid code, and succeeds in arriving at the array x = (-5., -4. -3 �� 5) as implied by the coding.

Both gFortran and iFort also accept it as valid code, and both return an identical set of results, x = (-5, -4, 1, 1, 1, 1, �. 1), i.e. different from FTN95.

Should not all the compilers (including FTN95) not reject this line of code?

My simple understanding is that the steps within the FORALL structure can be theoretically executed in any order i.e. when evaluating x(i) = x(i-1) + dx, the value of x(i-1) may not necessarily have been previously calculated, so the compliers should reject the situation where x(i) and x(j) appear on either side of the = sign? Is my understanding correct?

Can anybody explain what I am observing here? Very confused by this, especially when the three compiler test for any code returns different answers.

[mecej4]

The code is invalid because x(2:9) are not defined when they are used in the FORALL assignment statement, except when one specific order of evaluation is followed on a single processor shared memory computer. Here is the relevant section of the F2008 standard:

Execution of a forall-assignment-stmt that is an assignment-stmt causes the evaluation of expr and all expressions within variable for all active combinations of index-name values. These evaluations may be done in any order. After all these evaluations have been performed, each expr value is assigned to the corresponding variable. The assignments may occur in any order.

Just as with any other assignment involving expressions that contain undefined variables, the compiler is not required to detect or do anything specific when given this code with errors.

I said above that there is one specific order of evaluation for which no usage of undefined variables occurs. That is the natural sequential order i = 2, 3, ..., 10. It seems that FTN95 picks this order, because compiling and running with the /undef option does not cause a runtime error, and the output results reported for FTN95 support this conjecture.

[Kenneth_Smith]

Mecej4,

Thank you for your detailed discussion which is very informative.

You have confirmed my somewhat vague initial thoughts on the code being invalid (although FTN95 suggested otherwise), and explained why.

[simon]

I believe that DO FORALL has been superseded by DO CONCURRENT

[JohnCampbell]

You can't use code in FORALL where order is important. The same applies in a !$OMP DO

Try "x(i) = xmin + (i-1)*dx"