Failure within MODULO with 32 bit integers ?

The intrinsic function MODULO returns a wrong result when used with 32 bit integers, as shown in the following example:

PROGRAM div
IMPLICIT NONE
INTEGER, PARAMETER :: k=3
INTEGER(KIND=k) :: a,b
b=43*144*16
a=27*144*16
WRITE(*,*) 'a = ', a, '  b = ', b, '  MOD(a,b)    = ', MOD(a,b)
WRITE(*,*) 'b = ', b, '  a = ', a, '  MOD(b,a)    = ', MOD(b,a)
WRITE(*,*) 'a = ', a, '  b = ', b, '  MODULO(a,b) = ', MODULO(a,b)
WRITE(*,*) 'b = ', b, '  a = ', a, '  MODULO(b,a) = ', MODULO(b,a)
END PROGRAM div

Output for k=3 a = 62208 b = 99072 MOD(a,b) = 62208 b = 99072 a = 62208 MOD(b,a) = 36864 a = 62208 b = 99072 MODULO(a,b) = 62208 b = 99072 a = 62208 MODULO(b,a) = 99072 Output for k=4 (correct) a = 62208 b = 99072 MOD(a,b) = 62208 b = 99072 a = 62208 MOD(b,a) = 36864 a = 62208 b = 99072 MODULO(a,b) = 62208 b = 99072 a = 62208 MODULO(b,a) = 36864 Compiler version: FTN95 8.80

With 8.80, I find that the bug that you reported does not occur when /64 is not used.

Did you use the same version of the compiler?

mecej4

I may confirm that the bug only occurs when the /64 option is used, that's why I made this report in the 64-bit subforum only. In both cases (with and without /64 option) the version 8.80.0 of the compiler has been used.

Thank you for this bug report which I have logged for investigation.

I can confirm that the bug occurs with Ver 8.74 and ftn95 modulo /64 /lgo, but not with ftn95 modulo /lgo, or kind=4 ( I modified the format to better report in a Plato execute window and test simple MODULO)

PROGRAM div
IMPLICIT NONE
INTEGER, PARAMETER :: k=selected_int_kind(9)
INTEGER(KIND=k) :: a,b

write (*,11) 'Kind =',k

b=43*144*16
a=27*144*16

WRITE(*,11) 'a = ', a, '  b = ', b, '  MOD(a,b)    = ', MOD(a,b)
WRITE(*,11) 'b = ', b, '  a = ', a, '  MOD(b,a)    = ', MOD(b,a)
WRITE(*,11) 'a = ', a, '  b = ', b, '  MODULO(a,b) = ', MODULO(a,b)
WRITE(*,11) 'b = ', b, '  a = ', a, '  MODULO(b,a) = ', MODULO(b,a)
WRITE(*,11) 'a = ', a, '  b = ', b, '  MODULx(a,b) = ', MODULx(a,b)
WRITE(*,11) 'b = ', b, '  a = ', a, '  MODULx(b,a) = ', MODULx(b,a)
11 format (a,i8,a,i8,a,i8)

contains

integer function modulx (a,b)
INTEGER, PARAMETER :: k=selected_int_kind(9)
INTEGER(KIND=k) :: a,b, n
n = a/b
modulx = a-b*n
end function modulx

END PROGRAM div

Addendum

16 bit variables seem to play a role in the origin of the bug, see example below, compiled with FTN95 /64 (Version 8.80)

PROGRAM div
IMPLICIT NONE
INTEGER, PARAMETER :: k=3
INTEGER(KIND=k) :: i
DO i=2,2**17
  IF (MODULO(3*i,2*i) >= 2*i) THEN
    WRITE(*,'(A,I0)') 'Failure above ',2*i
    EXIT
  END IF
END DO
END PROGRAM div

Output: Failure above 65536

There are no 16-bit variables in the program that you show.

Using the MODULO function generates a call to routine JMOD in the FTN95 64-bit DLLs, and I suspect that the bug is in JMOD or another routine that is called from JMOD.

It is true that 2^16 = 65536, but that does not by itself justify concluding that 16-bit variables/registers are responsible for the bug.

mecej4 You are right, of course. My wording was imprecise, I only meant that 16 bit variables could possibly play a role. Nothing more, by no means a stringent conclusion. I am also aware that the published code does not contain 16 bit variables. Thank you for investigating the DLL call.

This bug has now been fixed in the next release of clearwin64.dll.

Paul

Thank you for solving this bug.