Limitation for the counter of a loop

Is the allowed value for the counter i of a loop limited to HUGE(i)-1 ? The following code produces an infinite loop for KIND=1, 2, 3 and 4.

PROGRAM Loop
IMPLICIT NONE
INTEGER(KIND=1) i
DO i=HUGE(i)-1, HUGE(i)
  WRITE(*,*) i
END DO
END PROGRAM Loop

Nota:

Same results using Win32 and x64 versions Compiler Version 8.61 Compiler options: /LINK resp. /64 /LINK

jib

At first sight it looks like FTN95 does not handle this case correctly.

At the moment the upper limit must be HUGE(i)-1.

For an upper limit of HUGE(i) FTN95 does the comparison at the wrong point and integer overflow kicks in. If you use /CHECK then you get an overflow failure.

For the moment you can't use this last value as the upper limit for this kind of DO construct. You should use HUGE(i)-1 or an alternative kind of DO construct.

I have a feeling that this is related in some way to the advice not to rely on the value of the loop index on completion of a loop (although you can, allegedly, if you jump out of the loop -I'm far too conservative a programmer to even do that). I remember reading that some versions of Fortran exit the loop on completion with the index set to 0 or -1, or if you are lucky (!) to the maximum count +1. It seems that quite possibly FTN95 falls into the latter category.

Incidentally, I can see why the maximum value for the index might just be a concern with INTEGER*1, *2 or 4, but surely not with INTEGER8.

Or are you counting virus cells for Prof Ferguson at Imperial College?

My note to Paul is that it isn't the behaviour that is wrong, it's the fact that it isn't documented. (Or not easily discoverable).

Eddie

This can be made to work as follows:

PROGRAM Loop
IMPLICIT NONE
INTEGER(KIND=4) i

DO i = HUGE(i)-1, HUGE(i), 1   !STARTVAL, ENDVAL, INC
  
  WRITE(*,*) i
  IF (I .EQ. HUGE(i)) EXIT   !Prevents I reaching HUGE(i)+1, as FTN95 returns +INC on ENDVAL following normal exit from do loop
    
END DO
END PROGRAM Loop

A future release of FTN95 (probably not the next) will either provide a compile time warning of this behaviour or will plant code to correct it. This will only occur when the upper limit is a literal constant.

I find this a very contrived example. 'DO i = 1,huge(i)' fails on all compilers I have available.

I don't really want all DO loops to be modified with a more sophistocated test, just for an extreme case that is extremely rare.

I have never had this problem in production code in over 40 years !!

John

Thanks for the feedback. The proposed fix will only relate to the case where HUGE(some_integer) appears literally in the code as the upper limit.

John May I relate the whole genesis of this very contrived sample program. While experimentating with integers (KIND=1) for bitewise purpose, I encountered an overflow at runtime for 127 (as literal) as endvalue (without having set the /CHECK option, mea culpa) . To see what happens for other integer kinds without having to type the literal value of the maximal settable endvalue (I am quite lazy), I used the HUGE function. So arised this very contrived example without any relation to practice. As I haven't find any hints for this behaviour, I allowed myself to ask about an unexpected limitation of the counter of a loop, for my personal education, I unfortunately haven't decennies of programming practice.

This issue has now been addressed for a future release of FTN95.

In future the compiler will provide a compile time warning when the value of the DO loop upper limit appears literally as the constant value of HUGE(i), where i is the current DO loop index.

In such cases it is guaranteed that you will get integer overflow unless you also include an alternative test to exit the loop.

Paul Thanks for the handling of my question. The compile time warning may help beginners like me in such cases.