forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Code Generation Bug
Goto page Previous  1, 2
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
mecej4



Joined: 31 Oct 2006
Posts: 1093

PostPosted: Sat Sep 29, 2018 6:39 pm    Post subject: Code generation bug, 32 and 64 bit, unaffected by options Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5837
Location: Salford, UK

PostPosted: Sat Sep 29, 2018 8:37 pm    Post subject: Reply with quote

Many thanks for your effort and patience. We will investigate the issue.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5837
Location: Salford, UK

PostPosted: Tue Apr 02, 2019 9:20 am    Post subject: Reply with quote

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
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2079
Location: Sydney

PostPosted: Wed Apr 03, 2019 7:54 am    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5837
Location: Salford, UK

PostPosted: Wed Apr 03, 2019 8:32 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
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