FTN95 /64 fails to catch integer overflow

The small test program given below causes an integer overflow when a value larger than 127 is attempted to be stored into an array element of type INTEGER(kind=1), even though /CHECKMATE /64 was used when compiling.

The 32-bit program from the same source code, compiled with /CHECKMATE, does cause the overflow to be trapped.

I used Version 8.64 of the compiler.

      PROGRAM Sim_pop
         IMPLICIT NONE
         INTEGER :: a,b, n
         LOGICAL, DIMENSION(:,:), ALLOCATABLE :: pop
         INTEGER(kind=2), DIMENSION(:,:), ALLOCATABLE :: sta
         INTEGER :: startc
         REAL*8, DIMENSION(1:2) :: p
         INTEGER(kind=1), ALLOCATABLE, DIMENSION(:,:) :: reg0
         INTEGER, DIMENSION(3) :: error
         !
         n = 150
         CALL random_seed(PUT = (/ 23 /))
!
         ALLOCATE(pop(1:n, 1:n), STAT = error(1))
         ALLOCATE(sta(1:n, 1:n), STAT = error(2))
         ALLOCATE(reg0(1:4, 1:2),STAT = error(3)) 
         IF (ANY(ERROR /= 0)) STOP 'Error allocating arrays'
         
         startc   = 0
         pop(:,:) = .FALSE.
         sta(:,:) = -1
!
         DO WHILE (startc < 4)
            CALL random_number(p)
            a = floor(1.d0 + p(1) * (DBLE(n)))
            b = floor(1.d0 + p(2) * (DBLE(n)))
            IF (.not. pop(a,b)) THEN
               pop(a,b) = .TRUE.
               sta(a,b) = -1
               startc = startc + 1
               reg0(startc,:) = (/ a, b /)   ! <<<=== Integer Overflow when startc = 3
            END IF
         END DO
         STOP
      END PROGRAM

Should it catch integer overflow ? Isn't this the basis of many random number generators ? (although no longer needed with intrinsics) Even SIZE overflows in /64 if array size >= 2^31

(btw, why has ^ never replaced ** as an operator ? I am surprised there has been no interest in this addition.)

John,

You would think that such errors should be caught when a compiler setting is used that is intended to catch such errors, wouldn't you? In raw mode, perhaps not.

Was ^ available in the early 6 bit card codes? But given the amount of dross subsequently imported into Fortran, I'm with you that something as useful as this never made it. Of course,it may well be in some later standard, such as Fortran 2050.

Eddie

mecej4

Thanks for this.

This failure has been fixed for the next release of FTN95.