Q about use of ISHFTC

[WSinc]

This is supposed to do a circular shift of L bits by an amount amt.

integer(2) x,y,L,amt

y=ishftc(X,amt,L)

This worked fine when L and amt were typed as above, but when I
mistyped amt and L (the quantities still fit well within range) it didn't
do a shift at all, i.e Y was set = to X.

If there was a problem with the typing, wouldn't the compiler flag it?
In other words, do all arguments have to be typed with the same integer length?

If not, what would be the default output length?

The on-line blurb about ISHFTC does not discuss this issue - - - -
Or maybe I wasn't looking where I should have (?)

Here is a more complete test case:

PROGRAM TEST_shift
implicit NONE
! integer(2) ilen,ish ! works
integer(1) ilen,ish ! fails
integer(2) X,Y
x=7
ilen=13
do ish=1,26
Y=ishftc(X,ish,ilen)
print 101,"Y=",Y
101 format(A,B17.16)
enddo
pause "exiting"
end program

[Steven_L_Intel1]

Now THIS is a compiler bug. I'll report it to the developers. Thanks. Issue ID is DPD200152557.

[WSinc]

Glad to be of help.

I can't help wondering the same issue might apply to any other of
the bit manipulation functions, or just this one (?)

Might be worth looking onto - -

[Steven_L_Intel1]

I've already made that suggestion. What is happening is that the compiled code is calling the INTEGER(2) library routine for ISHFTC, which is correct, but it is failing to "promote" the second and third arguments to INTEGER(2) so is just passing a one-byte location. The library routine reads two bytes and gets garbage for the second one. I think that in this case the third argument, the size, is now larger than the BIT_SIZE of the first argument and the library routine just returns the original value.

[WSinc]

I noticed also that it fails for larger sizes of argument #1, namely
integer(4), but WORKS for integer(8).

The third argument is optional, right?
Just assumes the # bits of the quantity in argument #1 I believe.
So if arg #1 is integer(8), it would assume 64 if omitted.

Here's another test case for integer(8). Seems to work for
all sizes for args #2 and #3.

Makes a real pretty display too - - - :<)

[bash]PROGRAM TEST_shift
    implicit NONE    
    integer(1) ilen     ! I tried different combinations 
    integer(2) ish      ! of these. They all work....
    integer(8) X,Y
    x=-798734872349
    ilen=43
    do ish=1,430
      Y=ishftc(X,ish,ilen)
      print 101,"Y=",Y
101   format(A,B65.64)
    enddo
    pause "exiting"
    end program[/bash]

Hmm - why does it sometimes put garbage stuff inside the source listing?

[Steven_L_Intel1]

Yes, the third argument is optional - if absent, it is the same as BIT_SIZE of the first argument.

As for the code insertion tool - if you paste in bolded text, which you did, the HTML tags such as will be rendered as text.

[WSinc]

I was trying to make it MORE readable.
Guess it had the opposite effect.......

But, why does it split lines?
Is it doing something weird to tabs that I had in there?
I could make those visible before I insert the code.

For example, it split the Format statement, and split the comment on line 3.

[Steven_L_Intel1]

That's a forum bug. I thought it had been fixed, but apparently not. I have reported it.

[Steven_L_Intel1]

I expect the ISHFTC bug to be fixed in Update 2 of Fortran Composer XE 2011.