Silverfrost Forums

Welcome to our forums

Odd bug in CHECKMATE mode

17 Mar 2017 11:31 #19168

The following code fragment prints the value of k twice. The result should be that K=1, then K=0.

However, if the default integer type is set to 2, the results show 1 and 441344.

If you compile this for RELEASE with the same options, the error does not occur.

If I change the type of 'k' to INTEGER or INTEGER*2, the code will work as it should.

	character*1 ft_returned(1000000)
    integer*4 q,p,rows,cols,k
    do k=1,1000000
      ft_returned(k) = char(k)
    end do
    rows=7
    cols=15
    do p=0,rows-1
       do q=0,cols-1
          k = ichar(ft_returned((q)+(p*cols)+1))
          print *,k
          k = k / 64
          print *,k
          pause
       end do
    end do
    stop
    end
18 Mar 2017 12:27 (Edited: 18 Mar 2017 11:55) #19169

The following simplified version of the code also shows the error.

program wbug
implicit none
character :: ft = char(1)
integer k
k = ichar(ft) / 64
print *,k 
end 

Compile with ftn95 /defint_kind 2 /check. Outputs 520.

Works correctly if /64 is added.

18 Mar 2017 7:24 #19171

Thank you. I have made a note of this.

22 Mar 2017 6:59 #19203

This has now been fixed for the next release of FTN95.

11 Apr 2017 3:17 #19379

Any idea when that might be?

I found another occurrence of this same kind of error, this time with the divisor of 16. If I declare a variable 'SIXTEEN' and assign it the appropriate value, the all works fine.

Making me very nervous about my literal division of INT*4's with constants of a power of 2.

11 Apr 2017 6:14 #19381

As I recall, the problem only occurs when setting the default integer type to 2. For me that is not a good idea. There is rarely a need to minimise the amount of store in this way and (because this option is rarely used) there is a higher risk of being the first to discover a bug.

We don't have a planned date for the next release of FTN95 at the moment. It's not long since the last release but on the other hand significant improvements have been added in the mean time.

11 Apr 2017 2:02 #19392

Thanks, Paul. Was curious because I am transitioning over to the default being 32-bit integers, but have hesitated to do a release to my testers if there is a new version just over the horizon!

I'll finish my transition, and await the new compiler with its fixes and features!

Bill

Please login to reply.