
forums.silverfrost.com Welcome to the Silverfrost forums

View previous topic :: View next topic 
Author 
Message 
KL
Joined: 16 Nov 2009 Posts: 124

Posted: Tue Jul 31, 2018 4:50 pm Post subject: Error in forall? 


The following (meaningless) program results in an error:
Code: 
Program Driver_Broyden_B
Use DataTypes
Use CommonData_Broyden
Implicit None
integer (i4b) :: nDim = 4
Call Allocate_Broyden_B (nDim)
! #########################
Call Initialize_Broyden_B (nDim)
! #########################
write (*,*) ' mat_Broyden = ', mat_Broyden (1,1,3)
read (*,*)
End Program Driver_Broyden_B

Code: 
Module datatypes
Integer , Parameter :: i4b = Selected_int_kind (9)
Integer , Parameter :: i2b = Selected_int_kind (4)
Integer , Parameter :: i1b = Selected_int_kind (2)
Integer , Parameter :: sp = Kind (1.0)
Integer , Parameter :: dp = Kind (1.0d0)
Integer , Parameter :: xp = Selected_real_kind (18,99)
Integer , Parameter :: lgt = Kind (.true.)
End Module Datatypes

Code: 
Module CommonData_Broyden
Use DataTypes
Implicit None
Real (dp), Dimension (:,:,:), Allocatable , Save :: mat_Broyden
End Module CommonData_Broyden

Code: 
Subroutine Initialize_Broyden_B ( n )
Use DataTypes
Use CommonData_Broyden
Implicit None
Integer (i4b), Intent (in) :: n
Integer (i4b) :: i
mat_Broyden (1:n,1:n,1) = 0._dp
Forall (i=1:n) mat_Broyden (i, i, 1) = 1._dp
!  Solution already known
mat_Broyden (1:n, 1:n, 2 ) = 0._dp ! set QT to 0
mat_Broyden (1:n, 1:n, 3 ) = 0._dp ! set R to 0
!  set diagonal elements 1
Forall (i=1:n)
mat_Broyden (i, i ,2) = 1._dp
end forall
!  set diagonal elements B to R
Forall (i=1:n)
mat_Broyden (i, i, 3) = mat_Broyden (i, i, 1)
end forall
! Do i = 1, n
! mat_Broyden (i, i, 2) = 1._dp
! mat_Broyden (i, i, 3) = mat_Broyden (i, i, 1)
! End Do
End Subroutine Initialize_Broyden_B

Code: 
Subroutine Allocate_Broyden_B (n)
Use DataTypes
Use CommonData_Broyden
Implicit None
Integer (i4b), Intent (in) :: n
Allocate ( mat_Broyden (1:n,1:n,1:3) )
End Subroutine Allocate_Broyden_B

The error occurs in subroutine Initiate_Broyden_B (Floating point stack fault) and does not show if the do loop is used instead of the forall construct.
I cannot see that anything is wrong or have I overlooked something? I would like to add that I have used ftn95 8.3 PE and the latest Plato version.
Klaus [/code] 

Back to top 


mecej4
Joined: 31 Oct 2006 Posts: 933

Posted: Wed Aug 01, 2018 11:35 am Post subject: 


I can confirm that there is a basic code generation error with source codes containing FORALL in combination with some compiler options. I have simplified Klaus's example to the following simple program.
Code:  Program Driver
Implicit None
Real, Dimension (:,:,:), Allocatable :: Bmat
integer :: nD = 2, i
Allocate ( Bmat (1:nD,1:nD,1:nD) )
Bmat (1:nD,1:nD,1) = 0.
Do i=1, nD
Bmat(i,i,1) = 1.
End Do
Forall (i=1:nD) Bmat (i, i, nD) = Bmat (i, i, 1)
write (*,*) ' Bmat = ', Bmat (1,1,nD)
End Program Driver 
FTN95 versions 8.30.169 and 8.30.279 (beta), with or without /DEBUG and with or without /64, generate code that uses the value of a floating point number as an address, the contents of which are accessed. Depending on the previously loaded (or undefined) value of this malformed "address", the attempted memory read may or may not cause an access violation.
The bug disappears (or may hide) when /opt is used.
Here is the runtime error from the 32bit EXE of this program.
Code:  Runtime error from program:s:\ftn95\broy5.exe
Access Violation
The instruction at address 004012aa attempted to read from location 3f800000
00401000 main [+02aa]
eax=00000000 ebx=3f800000 ecx=00000002
edx=00000000 esi=00000004 edi=00000002
ebp=0360fce0 esp=0360fc58 IOPL=2
ds=002b es=002b fs=0053
gs=002b cs=0023 ss=002b
flgs=00010202 [NC OP NZ SN DN NV]
004012aa fld [ebx+edx*4]
004012ae mov eax,[00404000]
004012b4 fstp [eax+esi*4] 
Note that 3F800000 is the IEEE32 representation of 1.0, which has now been loaded into EBX and is being used as the base address in the FLD instruction. The same problem affects the R/M used in the subsequent FSTP instruction.
If double precision reals are used, as in Klaus's test code, the low32 bits of the 64bit IEEE representation of 1.0_dp will be all 0, so an attempt may be made to read memory at address zero.
The bug is present in FTN95 7.20.0 as well.
Last edited by mecej4 on Sat Aug 04, 2018 3:59 am; edited 3 times in total 

Back to top 


KL
Joined: 16 Nov 2009 Posts: 124

Posted: Wed Aug 01, 2018 2:58 pm Post subject: 


Thank you very much, Mecej4, for your interesting contribution.
Klaus 

Back to top 


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

Posted: Thu Aug 02, 2018 4:24 am Post subject: 


Does FTN95 take a copy of Bmat for this FORALL ?
In F 2018, FORALL has now been labeled as obsolete, together with COMMON and EQUIVALENCE
FORALL is a feature that few compilers embraced, either for parallel calculation or for optimisation of DO order for memory/vector optimisation.
I mostly preferred the simplicity of DO and rarely utilised the mask option. 

Back to top 


DanRRight
Joined: 10 Mar 2008 Posts: 1864 Location: South Pole, Antarctica

Posted: Thu Aug 02, 2018 9:06 am Post subject: 


Why the hell these brain challenged made COMMON obsolete? Always happy with the dumbest compilers they always complained about COMMON but never tried FTN95 to find how good it can be actually implemented. 

Back to top 


LitusSaxonicum
Joined: 23 Aug 2005 Posts: 1812 Location: Yateley, Hants, UK

Posted: Thu Aug 02, 2018 2:50 pm Post subject: 


I'm bemused by the FORALL problem. Does it mean that FORALL never worked? If it never worked, why has it taken until now to discover it? Is it that people were content to accept silly answers (if they all used /OPT, and it doesn't work there)? Or did it work onceuponatime, and somewhere along the line stopped working? If so, why didn't anyone discover it before Klaus & Mecej4?
Applying Occam's Razor: the simplest explanation is that it never worked, but nobody ever used it until Klaus tried ...
Dan, what you have to understand is that people on the Fortran Committee don't like the way Fortran is, and has been, and want it to be something else. My view is that they haven't got a clue what Fortran programmers want, which is why there are no tools for graphics or building modern user interfaces in the standard.
Personally, I won't miss FORALL  never used it, and DO loops are better anyway (as demonstrated by Klaus  they work!). I also won't miss COMMON or EQUIVALENCE, for the simple reason that by the time they have well and truly disappeared from FORTRAN, I expect to be long dead.
Incidentally, if Broyden used FORTRAN back in the mid 1960s, he didn't use FORALL. In fact, he probably used Algol60 instead.
Eddie 

Back to top 


PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 5437 Location: Salford, UK

Posted: Fri Aug 03, 2018 7:51 am Post subject: 


Thanks to everyone for this feedback. I have made a note that this needs fixing. 

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
