Program crash for array copy with ifort
fortran, fortran95, intel-fortran
Solution
Your program is correct (though I would prefer allocatable to pointer if you do not need to be able to repoint it). The problem is that ifort by default places all array temporaries on the stack, no matter how large they are. And it seems to need an array temporary for the copy operation you are doing here. To work around ifort's stupid default behavior, always use the -heap-arrays flag when compiling. I.e.
ifort -o test test.f90 -heap-arrays 1600
The number behind -heap-arrays is the threshold where it should begin using the heap. For sizes below this, the stack is used. I chose a pretty low number here - you can probably safely use higher ones. In theory stack arrays are faster, but the difference is usually totally negligible. I wish intel would fix this behavior. Every other compiler has sensible defaults for this setting.
Problem
This program crashes with `Illegal instruction: 4` on MacOSX Lion and ifort (IFORT) 12.1.0 20111011 ``` program foo real, pointer :: a(:,:), b(:,:) allocate(a(5400, 5400)) allocate(b(5400, 3600)) a=1.0 b(:, 1:3600) = a(:, 1:3600) print *, a print *, b deallocate(a) deallocate(b) end program ``` The same program works with gfortran. I don't see any problem. Any ideas ? Unrolling the copy and performing the explicit loop over the columns works in both compilers. Note that with allocatable instead of pointer I have no problems. The behavior is the same if the statement is either inside a module or not. I confirm the same behavior on ifort (IFORT) 12.1.3 20120130. Apparently, no problem occurs with Linux and ifort 12.1.5 I tried to increase the stack size with the following linking options `ifort -Wl,-stack_size,0x40000000,-stack_addr,0xf0000000 test.f90` but I still get the same error. Increasing ulimit -s to hard same problem. Edit 2: I did some more debugging and apparently the problem happens when the array splicing operation ``` b(:, 1:3600) = a(:, 1:3600) ``` involves a value suspiciously close to 16 M of data. I am comparing the opcodes produced, but if there is a way to see an intermediate code form that is more communicative, I'd gladly appreciate it.