View previous topic :: View next topic |
Author |
Message |
jlb
Joined: 21 Oct 2020 Posts: 45
|
Posted: Mon Nov 02, 2020 2:33 pm Post subject: 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.
Code: | 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
Last edited by jlb on Tue Nov 03, 2020 3:48 pm; edited 1 time in total |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Mon Nov 02, 2020 4:03 pm Post subject: |
|
|
jib
At first sight it looks like FTN95 does not handle this case correctly. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Mon Nov 02, 2020 4:58 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Mon Nov 02, 2020 5:58 pm Post subject: |
|
|
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 INTEGER*8.
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 |
|
Back to top |
|
|
Kenneth_Smith
Joined: 18 May 2012 Posts: 697 Location: Hamilton, Lanarkshire, Scotland.
|
Posted: Mon Nov 02, 2020 10:03 pm Post subject: |
|
|
This can be made to work as follows:
Code: | 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 |
|
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Tue Nov 10, 2020 3:52 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Thu Nov 12, 2020 2:56 am Post subject: |
|
|
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 !! |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Thu Nov 12, 2020 7:55 am Post subject: |
|
|
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. |
|
Back to top |
|
|
jlb
Joined: 21 Oct 2020 Posts: 45
|
Posted: Thu Nov 12, 2020 11:27 am Post subject: |
|
|
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. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Thu Nov 12, 2020 11:30 am Post subject: |
|
|
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. |
|
Back to top |
|
|
jlb
Joined: 21 Oct 2020 Posts: 45
|
Posted: Thu Nov 12, 2020 11:45 am Post subject: |
|
|
Paul
Thanks for the handling of my question. The compile time warning may help beginners like me in such cases. |
|
Back to top |
|
|
|