forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Limitation for the counter of a loop

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
jlb



Joined: 21 Oct 2020
Posts: 5

PostPosted: Mon Nov 02, 2020 2:33 pm    Post subject: Limitation for the counter of a loop Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6593
Location: Salford, UK

PostPosted: Mon Nov 02, 2020 4:03 pm    Post subject: Reply with quote

jib

At first sight it looks like FTN95 does not handle this case correctly.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6593
Location: Salford, UK

PostPosted: Mon Nov 02, 2020 4:58 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2187
Location: Yateley, Hants, UK

PostPosted: Mon Nov 02, 2020 5:58 pm    Post subject: Reply with quote

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
View user's profile Send private message
Kenneth_Smith



Joined: 18 May 2012
Posts: 378
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Mon Nov 02, 2020 10:03 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6593
Location: Salford, UK

PostPosted: Tue Nov 10, 2020 3:52 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
JohnCampbell



Joined: 16 Feb 2006
Posts: 2239
Location: Sydney

PostPosted: Thu Nov 12, 2020 2:56 am    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6593
Location: Salford, UK

PostPosted: Thu Nov 12, 2020 7:55 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
jlb



Joined: 21 Oct 2020
Posts: 5

PostPosted: Thu Nov 12, 2020 11:27 am    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6593
Location: Salford, UK

PostPosted: Thu Nov 12, 2020 11:30 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
jlb



Joined: 21 Oct 2020
Posts: 5

PostPosted: Thu Nov 12, 2020 11:45 am    Post subject: Reply with quote

Paul
Thanks for the handling of my question. The compile time warning may help beginners like me in such cases.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group