topic Use ALLOCATABLE instead of in Intel® Fortran Compiler

Segfault when assigning two pointer arrays (ifort 13.0.1)

anton-d — Wed, 15 Jan 2014 16:11:56 GMT

Hi,

i get a segfault with ifort 13.0.1 when running the following program

program tmp
implicit none

integer, parameter:: n=5*10**6
real, pointer:: a(:),b(:)

allocate(a(n))
allocate(b(n))

a=b

end program

The cause seems to be the large size of the arrays. It does not happen for n=10**6.

Regards

Anton

You very likely have reach

Heinz_B_Intel — Wed, 15 Jan 2014 18:46:17 GMT

You very likely have reach the limit of your stack size. Please set this to unlimited: ulimit -s unlimited.

Using "ulimit -s unlimited"

anton-d — Thu, 16 Jan 2014 08:38:09 GMT

Using "ulimit -s unlimited" solves the problem.

Can this setting have unexpected drawbacks?

And also, are pointer arrays allocated on the stack? I don't observe this problem with allocatable arrays. So they are allocated on the heap, correct?

Many thanks

Anton

No, the issue is that a temp

Lorri_M_Intel — Thu, 16 Jan 2014 18:47:49 GMT

No, the issue is that a temp had to be created because we can't reliably know that the target of the two pointers do not overlap.

With actual allocatables, we do know that they do not overlap, and so do not need the temp.

By default, however, temps are put on the stack, although this can be changed using the -heap-arrays command line switch.

--Lorri

Thanks for the explantion.

anton-d — Fri, 17 Jan 2014 10:32:21 GMT

Thanks for the explantion. For very large arrays the creation of a temp array could be undersirable. Is there a way to prevent this? For example using a loop instead of whole array asignment?

Regards

Anton

Use ALLOCATABLE instead of

Steven_L_Intel1 — Sat, 18 Jan 2014 14:09:39 GMT

Use ALLOCATABLE instead of POINTER unless you will be using pointer assignment. With ALLOCATABLE the compiler should not use a temp.

Lorri, Steve,

jimdempseyatthecove — Mon, 20 Jan 2014 13:28:57 GMT

Lorri, Steve,

In this case (a=b where a and b are pointers and memory is stride 1), there is no reason for a temp to be created. When both pointer's strides are 1 call memmove (which could call one of two flavors of __intel_fast_memcpy: front-to-back and back-to-front).

When the pointers are not stride 1, you could fall back to making an extra copy, but I would rather see more work performed to see if the extra copy is absolutely required. IOW only when overlap .AND. when overlap cannot be handled by choice of front-to-back or back-to-front. Such a case might be where you have an overlap and different strides.

Your compiler optimization team goes to extremes to get the most efficient vectorization, this issue would be relatively trivial to resolve. Considering that the current method performs a memory R+W+R+W as opposed to R+W, it would appear to be "low hanging fruit" as an optimization candidate.

Jim Dempsey

Jim, in most cases use of

Steven_L_Intel1 — Mon, 20 Jan 2014 14:45:12 GMT

Jim, in most cases use of ALLOCATABLE arrays is the better solution. The complex code needed to do the additional checking and various choices would tend to inhibit optimizations. Fortran 2008 adds the CONTIGUOUS attribute which could be used by the compiler to eliminate the temp. As it happens, the current version doesn't do that but a future version will. The programmer should choose the appropriate language syntax.