forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Error in forall?

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
KL



Joined: 16 Nov 2009
Posts: 144

PostPosted: Tue Jul 31, 2018 4:50 pm    Post subject: Error in forall? Reply with quote

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
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Wed Aug 01, 2018 11:35 am    Post subject: Reply with quote

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
View user's profile Send private message
KL



Joined: 16 Nov 2009
Posts: 144

PostPosted: Wed Aug 01, 2018 2:58 pm    Post subject: Reply with quote

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

Klaus
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Thu Aug 02, 2018 4:24 am    Post subject: Reply with quote

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
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Thu Aug 02, 2018 9:06 am    Post subject: Reply with quote

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
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Thu Aug 02, 2018 2:50 pm    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Fri Aug 03, 2018 7:51 am    Post subject: Reply with quote

Thanks to everyone for this feedback. I have made a note that this needs fixing.
Back to top
View user's profile Send private message AIM Address
KL



Joined: 16 Nov 2009
Posts: 144

PostPosted: Wed Nov 07, 2018 6:20 pm    Post subject: Reply with quote

Paul, has the "Forall"-problem been investigated?
Klaus
Back to top
View user's profile Send private message
KL



Joined: 16 Nov 2009
Posts: 144

PostPosted: Wed Nov 07, 2018 6:20 pm    Post subject: Reply with quote

Paul, has the "Forall"-problem been investigated?
Klaus
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Wed Nov 07, 2018 8:41 pm    Post subject: Reply with quote

Klaus

No this issue is still outstanding.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Wed Jul 31, 2019 9:36 pm    Post subject: Reply with quote

This bug has now been fixed for the next release of FTN95.
Back to top
View user's profile Send private message AIM Address
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Sun Aug 04, 2019 1:34 am    Post subject: Reply with quote

.... hence avoiding everyone (well all scots users anyway) bursting into a chorus of that perennial ditty: FORALL Lang Syne Wink
_________________
''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 ... Smile "
Back to top
View user's profile Send private message
KL



Joined: 16 Nov 2009
Posts: 144

PostPosted: Thu Mar 26, 2020 10:49 am    Post subject: Reply with quote

It seems that in version 8.61 this bug has been fixed. Thank you very much.
Klaus
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Sun Mar 29, 2020 9:53 pm    Post subject: Reply with quote

... 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 ... Smile "
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
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