|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
mecej4
Joined: 31 Oct 2006 Posts: 1885
|
Posted: Sat Sep 29, 2018 6:39 pm Post subject: Code generation bug, 32 and 64 bit, unaffected by options |
|
|
Paul's comments are quite sensible, and until now I had not succeeded in making the register usage bug to come alive in any 64-bit code. More poking around shows that all versions of FTN95 (I tried 6.35, 7.2, which are 32-bit only; 8.1, 8.2 and 8.3, 32-bit and 64-bit) are probably afflicted by this bug. Here is a reliable and surprisingly short reproducer.
Code: | program salREGbug
implicit none
integer, parameter :: double = kind(0.d0)
integer :: l = 2, jbl(2) = (/ 1, 2 /)
real(double) :: alf = -3.86D-01
real(double) :: x(2) = (/ 1.61D-2, -2.69D0 /)
real(double) :: abl(3) = (/ 7.75D2, 3.93D2, 2.01D2 /)
!
call sub(l, abl, jbl, alf, x)
write(*,'(A,2x,2ES12.4)')'X = ',x
stop
end program
subroutine sub(l, abl, jbl, alf, x)
implicit none
integer, parameter :: double = kind(0.d0)
integer , intent(in) :: l, jbl(l)
real(double) , intent(in) :: alf, x(*)
real(double) , intent(in out) :: abl(l*(l+1)/2)
integer :: i, k
!
! FTN95 8.3 (32 and 64 bit) have errors in tracking usage of registers
! in the code generated from the source lines below.
!
! One or more registers may be overwritten with the values of
! more than one variable and the register contents are
! accessed later. Variable values, including the patterns used to
! initialise variables when /undef is used, may end up being used
! as base addresses of arrays.
!
k = 0
do i = 1, l
if (jbl(i) <= 0)cycle
where ( jbl(:i) > 0 ) &
abl(k+1:i+k) = abl(k+1:i+k) + alf*x(jbl(i))*x(jbl(:i))
k = i + k
end do
end subroutine |
I ran the versions of FTN95 that I listed using a number of options.
/checkmate
/check
-no option-
/opt
/opt /p6
/opt /64
/64
/64 /check
/64 /checkmate
The code aborted after an access violation in every one of the 37 runs. Note the improbable memory addresses from which a read is attempted at the point of the crash: with FTN95-8.30, the 32-bit program attempts to read from 0x20202020, and the 64-bit program attempts to read from 0x00000000.
The program has no errors; when run with, say, Gfortran, it gives:
Code: | X = 1.6100E-02 -2.6900E+00 |
Last edited by mecej4 on Sun Sep 30, 2018 1:02 am; edited 2 times in total |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7916 Location: Salford, UK
|
Posted: Sat Sep 29, 2018 8:37 pm Post subject: |
|
|
Many thanks for your effort and patience. We will investigate the issue. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7916 Location: Salford, UK
|
Posted: Tue Apr 02, 2019 9:20 am Post subject: |
|
|
The fault demonstrated in program salREGbug has now been fixed for the next release of FTN95.
For anyone who is interested, it turned out to be a conflict between the use of an array in a WHERE mask and its use in the body of the WHERE statement as the index of another array. In other contexts that usage would be interpreted as a vector subscript which in turn means that the compiler must plant code to create a copy of the primary array using the vector subscript.
In the present case an inappropriate vector subscript copy was being created which might have been OK had it not been created after it had been used.
The following code gives the same result and avoids all "snapshots" required when implementing WHERE in a serial processing compiler.
Code: | k = 0
do i = 1, l
do m = 1,i
if(jbl(m) > 0) abl(k+m) = abl(k+m) + alf*x(jbl(i))*x(jbl(m))
end do
k = i + k
end do
|
|
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Wed Apr 03, 2019 7:54 am Post subject: |
|
|
I am a bit confused by the WHERE construct, so I am a bit confused by Paul's comment "The following code gives the same result".
Is that the case ?
Going from: Code: | k = 0
do i = 1, l
if (jbl(i) <= 0)cycle
where ( jbl(:i) > 0 ) &
abl(k+1:i+k) = abl(k+1:i+k) + alf*x(jbl(i))*x(jbl(:i))
k = i + k
end do |
To: Code: | k = 0
do i = 1, l
do m = 1,i
if(jbl(m) > 0) abl(k+m) = abl(k+m) + alf*x(jbl(i))*x(jbl(m))
end do
k = i + k
end do |
My interpretation would be: Code: | k = 0
do i = 1, l
if (jbl(i) <= 0) cycle
do m = 1,i
if (jbl(m) > 0) abl(k+m) = abl(k+m) + (alf*x(jbl(i))) * x(jbl(m))
end do
k = k + i
end do |
I suspect in hindsight, my quibble is not related to the code generation bug, but I do find I much prefer an explicit DO loop to a WHERE statement.
In almost all cases where I adopt code including WHERE or conditional FORALL statements, I will replace the code with a DO loop, because the logic flow is clearer to me.
Possibly the reason that this bug has not been found for so long is many users of FTN95 have a similar view to me and rarely use WHERE.
I have not observed any performance advantage for adopting WHERE or FORALL in any F90+ compiler I have used.
Perhaps I should stop learning new Fortran ?
John |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7916 Location: Salford, UK
|
Posted: Wed Apr 03, 2019 8:32 am Post subject: |
|
|
John
Do you need an ENDDO in your snippet?
A WHERE statement/construct is already very tricky. I don't see how its interpretation could depend on its context (within an outer DO loop or not). But I might be wrong.
A WHERE can be expanded to an IF within a DO with the added complication that it must simulate a parallel process. So usually the compiler will also arrange to copy the arrays just in case there are side effects.
So on a serial processing machine a WHERE can be less efficient as well as being less readable. It is quite possible that the Fortran standards committee only intended WHERE to be used on parallel processing machines. |
|
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
|