INTEGER(KIND=4) expressions cannot be in logical expressions

Got this diagnostics above in this line where all variables are integer

    if(ang_k10.gt.0 .and. ncnf.gt.ang_k10) then   

or in the lines like this one i get shocking diagnostics pushing me to do logical comparison

   if(ang_k10.eq.0) then

*** The condition in an IF statement should be LOGICAL

Yes, ang_k10 is INTEGER(KIND=4) but why we can not compare integer numbers?

The following test runs OK for me. Note that kind = 4 will give 64 bit integers unless you use /alt_kinds.

program LL
integer(kind=4) ang_k10,ncnf
ang_k10 = 0
ncnf = 1
if(ang_k10.eq.0)then
  print*, 'OK1'
endif
ang_k10 = 1
ncnf = 2
if(ang_k10.gt.0 .and. ncnf.gt.ang_k10) then 
  print*, 'OK2'
endif  
end

Paul, Thanks for looking at this witchcraft. That why i am saying - its shocking...I really do not know what's to do...

BTW, your example works with both cases with and without /alt_kinds, and the code i am trying to use gives also the same diagnostics with and w/o /alt_kinds

Maybe the problem is some where else.

First try commenting out the offending lines to see what happens.

Dan,

This and your other post show code that was written assuming the value of KIND is fixed, which works with most other compilers that share the same KIND assumptions, but not FTN95. There are two areas that cause problems with this:

1. Declaring variables, eg REAL (8) or INTEGER(4) : The easiest portable solution is to use REAL8 and INTEGER4. I forget the long winded standard conforming syntax, which is usually placed in a module, in another file, that later is not listed with the file being compiled.
2. Constants, such as 1.2_8, or in the case of FTN95 1.2_3 for real10 constants. The easiest way I know to easily solve this is to use parameter definition of constants. Integer8 and Real*10 always pose problems here. Eg, what is 2_4 ?

Unfortunately this problem was introduced in the late 80's when the standard said the value of KIND was system dependent. Unfortunately FTN95 did not adopt the byte count value and the problem has remained. My exerience with /alt_kinds was that it did not work with constants. That was a long time ago, so I moved to alternative syntax and haven't tried again.

Again, my recomendation is don't waste your time with the KIND syntax and use the REAL8 and INTEGER4 syntax which always works. (There is probably some compiler out there that objects, but I haven't found it.)

Just thought of a new problem area: With 64-bit there is a transition from INTEGER4 to INTEGER8 for a number of variables being used, relating to memory address and array size (LOC is now INTEGER*8 for the memory address above 2gb, which works well with FTN95)

John

How about making this syntax like REAL(8) INTEGER(4) default? All use it.