|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
KL
Joined: 16 Nov 2009 Posts: 144
|
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: 1891
|
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 32-bit 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 IEEE-32 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 low-32 bits of the 64-bit 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: 144
|
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: 2556 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: 2826 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: 2390 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 once-upon-a-time, 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 Algol-60 instead.
Eddie |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7933 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 |
|
|
KL
Joined: 16 Nov 2009 Posts: 144
|
Posted: Wed Nov 07, 2018 6:20 pm Post subject: |
|
|
Paul, has the "Forall"-problem been investigated?
Klaus |
|
Back to top |
|
|
KL
Joined: 16 Nov 2009 Posts: 144
|
Posted: Wed Nov 07, 2018 6:20 pm Post subject: |
|
|
Paul, has the "Forall"-problem been investigated?
Klaus |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7933 Location: Salford, UK
|
Posted: Wed Nov 07, 2018 8:41 pm Post subject: |
|
|
Klaus
No this issue is still outstanding. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7933 Location: Salford, UK
|
Posted: Wed Jul 31, 2019 9:36 pm Post subject: |
|
|
This bug has now been fixed for the next release of FTN95. |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Sun Aug 04, 2019 1:34 am Post subject: |
|
|
.... hence avoiding everyone (well all scots users anyway) bursting into a chorus of that perennial ditty: FORALL Lang Syne _________________ ''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... " |
|
Back to top |
|
|
KL
Joined: 16 Nov 2009 Posts: 144
|
Posted: Thu Mar 26, 2020 10:49 am Post subject: |
|
|
It seems that in version 8.61 this bug has been fixed. Thank you very much.
Klaus |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Sun Mar 29, 2020 9:53 pm Post subject: |
|
|
... and presumeably in V8.5 and V8.60 as Paul posted in July lastyear that the fix would be in subsequent release _________________ ''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... " |
|
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
|