List of compiler errors?

[lklawrie]

If there is a list/file of compiler errors, I probably should know where to find them but I don't. And, V12 is not giving this error but some of my developers haven't upgraded -- still at 11.1

error #6362: The data types of the argument(s) are invalid. [ISHFT]

Any help or suggestions for them to get around this?

Linda

[Steven_L_Intel1]

We have a knowledge base article on each error message, though only some of them have detailed explanations.

For this one, there is a call to the ISHFT intrinsic but the compiler thinks that one or more of the arguments to the intrinsic have the wrong data type. The full error message might point to the particular argument in question. If 12.0 is not giving an error then perhaps we fixed a bug where the compiler got confused by something. Can you show me the call to ISHFT and the full declarations of each of the arguments?

[Steven_L_Intel1]

Linda,

Thanks for providing me with the source.

The problem has to do with this bit:

ISHFT(z'0000000000000001', Grid_Shift)

Where Grid_Shift is declared as INTEGER(8). The problem is that the hex constant here is being treated as INTEGER(4). It is an extension to have a "BOZ" constant as an argument to ISHFT (or most anywhere except in a DATA statement, with an exception for the INT and REAL intrinsics.) In this context, we allow it but treat the value as "default integer" unless the value would not fit in a default integer, but here it does.

Nevertheless, calling ISHFT with an INTEGER(4) first argument and INTEGER(8) second argument is ok - the compiler should "promote" the smaller argument to the larger kind. We had a bug in 11.1 where this was not working for BOZ constants and fixed that in 12.0.

The workaround is to change the code to read:

ISHFT(INT(z'0000000000000001'), Grid_Shift)

This not only allows 11.1 to compile it but also makes the code standard-conforming.

[lklawrie]

Quoting Steve Lionel (Intel)

The workaround is to change the code to read:

ISHFT(INT(z'0000000000000001'), Grid_Shift)

This not only allows 11.1 to compile it but also makes the code standard-conforming.

This may allow the code to compile but significantly changes the results.

Did you mean to say INT(z'0000000000000001',8)?

Linda

[Steven_L_Intel1]

Well, that works too.

[lklawrie]

I thought about that after I sent it -- INT should be generic and not change the two results, yes?

Is this a defect in the compiler? I know -- it's on the edge of usual Fortran.

Linda

[Steven_L_Intel1]

INT returns default integer without the KIND argument. As I mentioned, the compiler has an extension where it will promote kinds if you mix them in an intrinsc - it was a bug earlier that this did not work for BOZ constants.

However, now that I look at the standard, ISHFT does not require the kinds to be the same - I guess the bug was that the compiler was not properly handle BOZ constants there. It is non-standard to have a BOZ constant there, so I suggested the INT. There is no difference in the values, the result of the ISHFT with the INTEGER(4) first argument and INTEGER(8) second is INTEGER(8).

[lklawrie]

Well, something sure made a difference in my results. And when I removed that INT, it went back to good.

I will have to look deeper when I have time.

Linda

[Steven_L_Intel1]

I did an experiment and indeed you need the KIND=8 in the INT. If you shift more than 31 without that, the result is zero. I guess the shift is done first and then the result converted - not exactly what I would expect, but it's understandable.

[JVanB]

[fortran]program ishft_test
! ifort prints 4 on the first line and 8 on the second.
! To be sure what you get with BOZ literals, use them
! in a standard-conforming way.
! gfortran prints out 4 and 16, BTW.
   implicit none
   integer(4) i
   integer(8) shift

   i = 1
   shift = 7
   write(*,*) kind(ishft(i,shift))
   write(*,*) kind(ishft(Z'0000000000000001',shift))
end program ishft_test
[/fortran]

[Steven_L_Intel1]

Yes, I had written much the same sort of program and got the same results. (gfortran prints 16? that seems a bit odd for this case.) More interesting is what the value of the ishft is when shift is, say, 34.