|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
jlb
Joined: 21 Oct 2020 Posts: 67
|
Posted: Mon Sep 20, 2021 7:01 pm Post subject: 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:
Code: | 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 |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1896
|
Posted: Tue Sep 21, 2021 2:34 am Post subject: |
|
|
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? |
|
Back to top |
|
|
jlb
Joined: 21 Oct 2020 Posts: 67
|
Posted: Tue Sep 21, 2021 9:57 am Post subject: |
|
|
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. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8016 Location: Salford, UK
|
Posted: Tue Sep 21, 2021 10:33 am Post subject: |
|
|
Thank you for this bug report which I have logged for investigation. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2584 Location: Sydney
|
Posted: Tue Sep 21, 2021 10:59 am Post subject: |
|
|
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)
Code: | 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 |
|
|
Back to top |
|
|
jlb
Joined: 21 Oct 2020 Posts: 67
|
Posted: Tue Sep 21, 2021 12:04 pm Post subject: |
|
|
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)
Code: | 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:
|
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1896
|
Posted: Wed Sep 22, 2021 12:07 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
jlb
Joined: 21 Oct 2020 Posts: 67
|
Posted: Wed Sep 22, 2021 2:07 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8016 Location: Salford, UK
|
Posted: Mon Oct 18, 2021 12:19 pm Post subject: |
|
|
This bug has now been fixed in the next release of clearwin64.dll. |
|
Back to top |
|
|
jlb
Joined: 21 Oct 2020 Posts: 67
|
Posted: Thu Oct 28, 2021 10:01 pm Post subject: |
|
|
Paul
Thank you for solving this bug. |
|
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
|