forums.silverfrost.com

[DanRRight]

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?

[PaulLaidler]

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

[DanRRight]

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

[PaulLaidler]

Maybe the problem is some where else.

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

[JohnCampbell]

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 REAL*8 and INTEGER*4. 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 real*10 constants. The easiest way I know to easily solve this is to use parameter definition of constants. Integer*8 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 REAL*8 and INTEGER*4 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 INTEGER*4 to INTEGER*8 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

[DanRRight]

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