Silverfrost Forums

Welcome to our forums

Error in forall?

31 Jul 2018 3:50 #22412

The following (meaningless) program results in an error:

  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



  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



  Module CommonData_Broyden
 
    Use DataTypes
    Implicit None

    Real (dp), Dimension (:,:,:), Allocatable , Save :: mat_Broyden  

  End Module CommonData_Broyden



  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



  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]

1 Aug 2018 10:35 (Edited: 4 Aug 2018 2:59) #22418

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.

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.

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.

1 Aug 2018 1:58 #22419

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

Klaus

2 Aug 2018 3:24 #22421

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.

2 Aug 2018 8:06 #22422

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.

2 Aug 2018 1:50 #22427

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

3 Aug 2018 6:51 #22431

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

7 Nov 2018 5:20 #22742

Paul, has the 'Forall'-problem been investigated? Klaus

7 Nov 2018 5:20 #22743

Paul, has the 'Forall'-problem been investigated? Klaus

7 Nov 2018 7:41 #22744

Klaus

No this issue is still outstanding.

31 Jul 2019 8:36 #24122

This bug has now been fixed for the next release of FTN95.

26 Mar 2020 9:49 #25113

It seems that in version 8.61 this bug has been fixed. Thank you very much. Klaus

Please login to reply.