Issue with ISHFT and 2 byte integers

I have encountered a bug with ISHFT when used with 2 byte integers (I can't reproduce it with 4 byte integers), it sometimes fails to work giving the result zero. Here is a small test case to demonstrate the problem:

Module TestData

 Integer*2, Save :: i2SH
 Integer*2, Save :: i2DM
 Integer*2, Save :: i2CL

End Module TestData

Module Test

  Contains

  Subroutine ISHFTTest()

    USE TestData
    Integer*2 :: i2SI, i2CP
    Integer*2 :: i2Test

    i2CP = i2CL
    i2SI = i2SH + i2DM
    i2Test = i2SI
    WRITE(*, *) i2SI, i2CP, LS(i2SI, i2CP), ISHFT(260s, 4s) ! 260, 4, 4160, 4160
    i2Test = i2SI
    WRITE(*, *) ISHFT(i2Test, i2CP) ! This should write 4160
    i2Test = i2SI
    WRITE(*, *) i2SI, i2CP, ISHFT(i2Test, i2CP) ! This should write 260, 4, 4160
    i2SI= LS(i2SI, i2CP)
    WRITE(*, *) i2SI ! This should write 4160

  End Subroutine ISHFTTest

End Module Test

Program Main

USE TestData
USE Test

  i2SH = 160
  i2CL = 4
  i2DM = 100

  Call ISHFTTest()
  

End Program

The expected output is:

260 4 4160 4160
4160
260 4 4160
4160

I actually get:

260 4 4160 4160
0
260 4 4160
4160

It is strange that the first the two identical ISHFT calls give differt results. This is with FTN95 v6.35 with no switches.

Thanks. I will log this for investigation.

Thank you. Note the trivial program:

Program Main
WRITE(*,*) ISHFT(256, -2)
End Program

Also fails to give the correct output.

Quoted from QuintinHill Thank you. Note the trivial program:

Program Main
WRITE(*,*) ISHFT(256, -2)
End Program

Also fails to give the correct output.

In this 256 is a 4 byte integer, so the problem or problems are not restricted to 2 byte integers.

This 'may' be evaluated by the compiler at 'compile time' since it is a constant expression.

For interest and clue to what it going on both of these alternatives work:

INTEGER :: L
L=-2
WRITE(*,*) ISHFT(256,L)

!**and**

INTEGER :: W
W=256
WRITE(*,*) ISHFT(W,-2)

There appears to be a problem with the PRINT statement as illustrated by the following test.

Program Main 
  integer*2 j,k,r
  j=260_2
  k=4_2
  r=ishft(j,k)
  print*, r,r,ishft(j,k)
  print*, r,ishft(j,k)
End Program 

Can you get ISHFT to fail elsewhere (other than in a PRINT statement)?

With the current FTN95 I get

         4160        4160        4160
         4160           0

You get different results with

Program Main 
  integer*2 j,k,r
  j=260_2
  k=4_2
  k=k
  r=ishft(j,k)
  print*, r,r,ishft(j,k)
  print*, r,ishft(j,k)
End Program 

so previously r was being evaluated at compile time.

It is beginning to look like one of the registers is not being freed. Leave it with me for now.

It seems to only happen with expressions evaluated by the compiler.

program main
   integer n, m, k

   n = ishft(256, -2)
   print *, n, '<-- Should be 64. But isn't'

   print *, ishft(256,-2), '<-- Should be 64. But isn't'

   m = 256
   k = -2
   print *, ishft(m,k), '<-- Should be 64. And is!'
end

Thanks for looking!

This bug has now been fixed for the next release.

Paul,

I can't find recent discussion, but it appears this problem has returned. The program in the opening post works for FTN95 /debug /lgo (ok), but FTN95 /check /lgo (fails)

I have been resurrecting some code that uses FILES@ and manipulates the DOS date and time fields. It fails with YY and also when repacking the adjusted date/time for GMT changes.

    implicit none
    integer*2 yymmdd, hhmmss, GMT_minutes
!
    integer*2 s2,mi,hh, dd,mo,yy, change
!...
         yy = ishft (yymmdd,-9)            ! 0-127    returns 0 with /check
!...
         hhmmss = s2
         hhmmss = ior ( ishft(mi,5),  hhmmss )
         hhmmss = ior ( ishft(hh,11), hhmmss )
!
         yymmdd = dd
         yymmdd = ior ( ishft(mo,5),  yymmdd )
         yymmdd = ior ( ishft(yy,9),  yymmdd )     !  reports integer overflow with /check

I even tried changing: yy = ishft (yymmdd,-9) ! 0-127 to yy = ishft (yymmdd,-9_2) ! 0-127 but this had no effect.

Changing from /check to /debug removed the problem. Do you need any further info ?

This bug has now been fixed for the next release of FTN95 and salflibc.dll.

It concerns 32 bit programs compiled with /undef. The issue is unrelated to that at the start of this thread but rather concerns new code that has been added to FTN95 in order to improve 'undef' checking.