Huge() as a loop limit

Accelerated Computing HPC Compilers Legacy PGI Compilers
1

Hello,

with PGI-Fortran 17.10 the code snippet below executes the loop 0 times.

Regards

Ben

program test
  implicit none

  integer ii
  do ii = 0, huge(1)
    write(*,*)ii
  end do

end program test
2

Default integer is integer*4. Try this

program test
implicit none

integer8 ii
do ii = 0, huge(1)
write(,*)ii
end do

end program test

You can also compile with “-i8”, but that can cause things to be treated integer*8 that are not (for example, constants and functions).

You may also want to add -Mlarge_arrays, if the arrays involved
are big, and you need to make any internal address-to-byte-offset
computation done in 64-bit integer math. Like a 16000 by 16000
array - the indices don’t need to be integer*8 but the address computation does. It causes a tiny slowdown, but does not cause
errors if used in all cases.

dave

3

Not sure that’s the issue. As you mention integer*8 does run, but for the original example compiling with -i8 and/or -8storage doesn’t (-i2 is the only case giving a truncation error at compile time).

Both gfortran and ifort with integer*4 will run the loop correctly.

Interestingly, numerical comparisons between 0 and huge(1) in default precision behave as expected (<, >, ==).

Finally, either

do ii = 1, huge(1)

or

do ii = 0, huge(1)-1

also run as expected at i*4, while using 0 or negative starting values in the loop trips off that behaviour.

Could you clarify how -Mlarge_arrays affects simple loops (no array involved here)?

Regards

Ben

4

You are correct! I did some checking and determined HUGE(1)
returns the largest default integer value (integer*4) and should be okay
for ii. huge(1)-1 does work as a loop limit.

I have filed TPR 24981 to address this.

thanks,
dave

5

Fortunately my colleagues read the Standard to me.

The rule broken here is that the do loop index “must be computable in the index type”. The loop index can go from one to huge(1), but is not
capable of expressing the range from 0 to huge(1) in the variable.

The TPR 24981 is closed as ‘not a bug’.

dave