Apologies as this may have been discussed before. Consider the following tiny program: program test_huge use iso_fortran_env, only: int8 integer(int8) :: i do i=-huge(i),huge(i) print "('i=',i10,' b=',b8.8)", i,i end do end ~ …

Here’s the relevant sections of the standard: 11.1.7.4 Execution of a DO construct 11.1.7.4.1. Loop initiation When the DO statement is executed, the DO construct becomes active. If loop-control is [ , ] do-variable = scalar-int-expr1 , scalar-int-expr2 [ , scalar-int-expr3 ] the following ste…

Yes, going up to huge() in a loop can cause problems, depending on how the compiler manages the loop bounds. See this thread: [image] Loops don't behave like they should I found a way to “break” do-loops. Consider this example, which approximates a loop from 1 to infinit…

There have been several discussions about this in the Fortran newsgroup and other forums. The counter on a DO is incremented before being tested so at the end of the loop the value would be 128, causing an overflow. The longest related discussion is probably https://groups.google.com/g/comp.lang.f…

[image] FedericoPerini: do i=-huge(i),huge(i) Note that -huge(i) will not return the smallest possible integer: print*, -huge(1) ! -> -2147483647 print*, -huge(1)-1 ! -> -2147483648 print*, -huge(1)-2 ! -> Error: Arithmetic overflow

Ah @urbanjost @vmagnin @ivanpribec , thank you for your answers - I had missed that discussion with the Forum search. The reason I found this issue is that I wanted a parameter array that tabulated a value for each possible integer(int8) value. So is it safe to say that the only deterministic way…

There are some additional subtleties here as well. The standard’s description of loop counters (and discussions about it seemed to indicate some compilers implement it this way), is that the number of iterations is actually calculated and used as the “counter”, i.e. the loop index and bounds are not…

Most compilers I tested don’t do that if I recall correctly. It was only one older version of nag which seemed to calculate the number of iterations first.

[image] everythingfunctional: This means that any loops that would execute more than huge(i) times are not possible. I.e. What that circa means in practice is, “all loops in Fortran should never involve more than half the unsigned integer capacity of that variable’s storage size”. wow, that’s…

[image] everythingfunctional: I’m guessing most of them do now. Thank you for the quotes, the standard is very clear and your explanation 100% matches that. Regarding your last comment, that’s probably where gfortran is still lagging behind (other compilers, latest versions, run that loop jus…

[image] FedericoPerini: … The reason I found this issue is that I wanted a parameter array that tabulated a value for each possible integer(int8) value. … Is this what you are looking for? use, intrinsic :: iso_fortran_env, only : I1 => int8, I4 => int32 integer(I4), parameter :: n(*) …

I think the quoted section 11.1.7.4 above explains how the trip count is evaluated and incremented. If you want to write portable code, then you should keep your code consistent with that, even if some compilers allow you to violate those constraints. Another problem with the original code is the v…

Loop variable reaching integer `huge` causes infinite loop

Help

vmagnin January 17, 2023, 1:04pm 2

Yes, going up to huge() in a loop can cause problems, depending on how the compiler manages the loop bounds. See this thread:

Topic		Replies	Views
Loops don't behave like they should	41	2740	March 9, 2022
Redefining loop variables in old FORTRAN? Help	73	2119	May 15, 2024
Trying to understand implied do loops Help	28	2283	November 18, 2022
Compiler support for one-trip do loops Help	17	274	May 5, 2026
Ending a do loop with continue Help	33	1530	October 8, 2024

Loop variable reaching integer `huge` causes infinite loop

Related topics