Bug report - Segmentation fault with intrinsic do loops

[ilinov]

Hi, my compiler version is:

Package ID: l_fcompxe_2011.5.220

Intel Fortran Compiler XE 12.0 Update 5 for Linux*

If you try to run the code below with the defaul compiler options it causes segmentation fault error:

-------------------------------------------

program bug

implicit none

integer(4) :: i,ii
integer(4) :: imax=1
integer(4),allocatable :: a(:)

do ii = 1, 24
!!! imax from 2 to 16777216; up to 64 Mb int arrays
imax = imax*2

allocate(a(imax))

a = [(i, i=1,imax,1)]
print *, ii, sum(a)

! reverse order fails at ii=22 in ifort
a = [(i, i=imax,1,-1)]
print *, ii, sum(a)

deallocate(a)

enddo
end program

[mecej4]

Assignments such as

a = [(i, i=1,imax,1)]

may provoke the compiler into creating a temporary variable on the stack for holding the expression value prior to the assignment to the LHS variable. Allow the program enough stack (over 64 Mb), and the segfault will go away.

The program, however, runs into integer overflow much earlier, so the results for imax > 2¹⁵ are junk.

[ilinov]

Okay, thanks! that was just an example without any deep meaning
So the issue was about the stack size.

Does it mean that it is more safe to use forall and do loops for big arrays?

[TimP]

Certainly, there are situations where an explicit DO loop avoids a hidden temporary allocation which occurs with array assignment, thus conserving stack or (with -heap-arrays) heap space.
There aren't many situations where FORALL can be recommended over DO, particularly now that ifort (but not many other compilers) support DO CONCURRENT. Certain usages of FORALL also create hidden temporary copies which are required for correct implementation.
I have examples where ifort DO loops also create unnecessary hidden allocations, but the situation is much less frequent with current ifort than it was with past versions.
I would not recommend against MATMUL, for example, simply on the basis that it tends to create temporaries which might be avoided by equivalent MKL library calls or DO loops.

[ilinov]

TimP, thank you very much for the detailed explanation!