|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
mecej4
Joined: 31 Oct 2006 Posts: 1895
|
Posted: Thu Aug 20, 2020 12:07 pm Post subject: 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.
Code: | 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 |
|
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Fri Aug 21, 2020 4:09 am Post subject: |
|
|
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.) |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2391 Location: Yateley, Hants, UK
|
Posted: Fri Aug 21, 2020 12:16 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Sat Aug 22, 2020 6:41 am Post subject: |
|
|
mecej4
Thanks for this. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Tue Aug 25, 2020 4:04 pm Post subject: |
|
|
This failure has been fixed for the next release of FTN95. |
|
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
|