
forums.silverfrost.com Welcome to the Silverfrost forums

View previous topic :: View next topic 
Author 
Message 
Kenneth_Smith
Joined: 18 May 2012 Posts: 710 Location: Hamilton, Lanarkshire, Scotland.

Posted: Fri Apr 14, 2023 10:11 pm Post subject: FORALL puzzle 


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(i1) + dx, the value of x(i1) 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.
Code:  program forall_puzzle
implicit none
integer, parameter :: n = 11
integer, parameter :: dp = kind(1.d0)
real(kind=dp) xmin, xmax, dx, x(n)
integer i
xmin = 5.d0
xmax = +5.d0
dx = (xmax  xmin)/dble(n1)
print*, 'dx = ', dx
x(1) = xmin
forall (i=2:n:1) x(i) = x(i1) + dx
!$$$$$$ ! Do loop alternative to forall
!$$$$$$ do i = 2, n, 1
!$$$$$$ x(i) = x(i1) + dx
!$$$$$$ end do
do i = 1, n
print*, i, x(i)
end do
end program forall_puzzle 


Back to top 


mecej4
Joined: 31 Oct 2006 Posts: 1896

Posted: Sat Apr 15, 2023 1:24 am Post subject: 


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 forallassignmentstmt that is an assignmentstmt causes the evaluation of expr and all expressions within variable for all active combinations of indexname 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. 

Back to top 


Kenneth_Smith
Joined: 18 May 2012 Posts: 710 Location: Hamilton, Lanarkshire, Scotland.

Posted: Sat Apr 15, 2023 3:14 pm Post subject: 


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. 

Back to top 


simon
Joined: 05 Jul 2006 Posts: 270

Posted: Sat Apr 15, 2023 4:22 pm Post subject: 


I believe that DO FORALL has been superseded by DO CONCURRENT 

Back to top 


JohnCampbell
Joined: 16 Feb 2006 Posts: 2584 Location: Sydney

Posted: Mon Apr 24, 2023 6:47 am Post subject: 


You can't use code in FORALL where order is important. The same applies in a !$OMP DO
Try "x(i) = xmin + (i1)*dx" 

Back to top 




You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum

Powered by phpBB © 2001, 2005 phpBB Group
