topic forall and stack overflow in Intel® Fortran Compiler

forall and stack overflow

hillyuanjp — Fri, 02 Jul 2010 08:06:20 GMT

I have found in following case Intel fortran would likely to give rise to stack overflow, where such error doesn't exist when usingother compliers like gfortran

eg1: a(:) = b(:)
eg2: forall( i=1:n )
a(i)=b(i)
end forall

However, in following case, it wouldn't likely give rise to the above error

eg3: a(:) = 0.d0
eg4: c = dot_product( a(:), b(:) )
eg5: do i=1,n
a(i)=b(i)
end do

My problems are:
1. eg1 and eg2 are generally a special implementation of eg5 and supposed more efficient because they provides more information into compiler. Although it depends on the internal implementation of intel compiler, but it is strange to gives rise tothe aboveprobelm.

2. Eg4 generally doesn't give rise to stack overflow. Is this so?

Much apprieciated for your anwser

forall and stack overflow

TimP — Fri, 02 Jul 2010 14:36:21 GMT

ifort expects a single-assignment forall to be preceded by !dir$ ivdep if you intend optimization. It's difficult to see why you would use forall in this case anyway.
There have been several previous articles posted on thes Fortran forums about the pros and cons of forall.

In f2008, there will be a do concurrent, which is a forall with fewer restrictions about optimization. There has been discussion implying that an initial implementation might be the IVDEP forall.

forall and stack overflow

Steven_L_Intel1 — Fri, 09 Jul 2010 18:31:02 GMT

The semantics of DO CONCURRENT are different from FORALL in terms of execution order within the construct. I don't think I'd go as far as Tim as to say that ifort "expects" an IVDEP directive. I do agree that FORALL is inappropriate here - the compiler will do a very good job of vectorization with:

a = b

Please do not use a(:) = b(:) - the semantics are subtly different and the extraneous (:) can prevent the compiler from doing the best job.