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 

Issue with ISHFT and 2 byte integers

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
QuintinHill



Joined: 13 Feb 2013
Posts: 4
Location: Winchester, United Kingdom

PostPosted: Thu Sep 19, 2013 2:10 pm    Post subject: Issue with ISHFT and 2 byte integers Reply with quote

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:
Code:

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:
Code:

260 4 4160 4160
4160
260 4 4160
4160


I actually get:
Code:

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


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

PostPosted: Thu Sep 19, 2013 2:28 pm    Post subject: Reply with quote

Thanks.
I will log this for investigation.
Back to top
View user's profile Send private message AIM Address
QuintinHill



Joined: 13 Feb 2013
Posts: 4
Location: Winchester, United Kingdom

PostPosted: Thu Sep 19, 2013 2:55 pm    Post subject: Reply with quote

Thank you. Note the trivial program:
Code:
Program Main
WRITE(*,*) ISHFT(256, -2)
End Program

Also fails to give the correct output.
Back to top
View user's profile Send private message
davidb



Joined: 17 Jul 2009
Posts: 560
Location: UK

PostPosted: Thu Sep 19, 2013 4:37 pm    Post subject: Re: Reply with quote

QuintinHill wrote:
Thank you. Note the trivial program:
Code:
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:

Code:

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

!**and**

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

_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Fri Nov 29, 2013 3:21 pm    Post subject: Reply with quote

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

Code:
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

Code:
         4160        4160        4160
         4160           0
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


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

PostPosted: Fri Nov 29, 2013 3:27 pm    Post subject: Reply with quote

You get different results with

Code:
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.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


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

PostPosted: Fri Nov 29, 2013 3:40 pm    Post subject: Reply with quote

It is beginning to look like one of the registers is not being freed.
Leave it with me for now.
Back to top
View user's profile Send private message AIM Address
davidb



Joined: 17 Jul 2009
Posts: 560
Location: UK

PostPosted: Fri Nov 29, 2013 10:26 pm    Post subject: Reply with quote

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

Code:

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!
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Mon Feb 10, 2014 2:31 pm    Post subject: Reply with quote

This bug has now been fixed for the next release.
Back to top
View user's profile Send private message AIM Address
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Sat May 23, 2020 3:18 pm    Post subject: Reply with quote

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.
Code:
    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 ?
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Mon May 25, 2020 8:02 am    Post subject: Reply with quote

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

 
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