Intel® Fortran Compiler - Increased stack usage of 8.0 or higher compilers causes segmentation fault

The Intel® Fortran Compilers 8.0 or higher allocate more temporaries on the stack than previous Intel Fortran compilers. Temporaries include automatic arrays and array sub-sections corresponding to actual arguments. If the program is not afforded adequate stack space at runtime relative to the total size of the temporaries, the program will terminate with a segmentation fault on Linux* and Mac OS* X or Signal 11 on Windows*.


On Linux*, the stack space can be increased using:
ulimit -s unlimited     for bash shell, or
limit stacksize unlimited     for csh shell.

On Mac OS* X Leopard:  simply use the -stack_size option to the linker
ifort -Wl,-stack_size,0x10000000  foo.f

or   ld -stack_size 0x10000000 -o foo foo.o

On Mac OS* X Tiger:  see the article, "How to increase the stack size on MAC OS X" by Eric Circlaeys, Consulting Engineer, Apple Computer Europe.

For example to increase to 256MB with either ld or ifort on Mac OS,

ld –stack_size 0x10000000 –o foo foo.o
or   ifort –Wl,-stack_size,0x10000000,-stack_addr,0xc0000000 foo.f


For Intel® Fortran Compilers 10.0 and above, all platforms:
The -heap-arrays compiler option directs the compiler to put the automatic arrays and arrays created for temporary computations on the heap instead of the stack. Note the 13.0 initial release of the compiler has a memory leak with the  -heap-arrays switch, so do not use it with this release. (Fixed in 13.0 Update 1 - Issue ID DPD200235943)


Linux: The size of "unlimited" varies by Linux configuration, so you may need to specify a larger, specific number to ulimit (for example, 999999999). On Linux also note that many 32bit Linux distributions ship with a pthread static library (libpthread.a) that at runtime will fix the stacksize to 2093056 bytes regardless of the ulimit setting. To avoid this problem do not link with the -static option or the -fast option. Instead of -fast, use options: -ipo -O3 -no-prec-div -xP . This only affects the 32bit Linux distributions and does not apply to the 64bit Linux distributions.

Mac OS X: stack "unlimiting" of the shell environment on Mac OS X is not possible.  The OS sets a ceiling for the maximum stack size, typically 64K.  Use the linker options shown above to increase stacksize.

Windows: On Windows, the stack space to reserved for the program is set using the /Fn compiler option, where n is the number of bytes.  Additionally, the stack reserve size can be specified through the Visual Studio IDE which adds the Microsoft Linker option /STACK: to the linker command line.  To set this, go to Property Pages>Configuration Properties>Linker>System>Stack Reserve Size. There you can specify the stack size in bytes in either decimal or C-language notation. If not specified, the default stack size is 1MB.

For more complete information about compiler optimizations, see our Optimization Notice.


Steve Lionel (Intel)'s picture

The memory leak described as being in the 13.0 initial release was fixed in 13.0 Update 1 (Composer XE 2013 Update 1). The internal issue tracking ID for this is DPD200235943.

John D B.'s picture

thanks for the info to create larger stack size. It worked.

nooj's picture

Is the memory leak fixed in 13.0.1? Lack of -heap-arrays is really messing me up, especially as OSX Lion is exclusive to v13 and vice-versa.

anonymous's picture

I was trying to compile my core in an MacOS X and it did not allowed me to change the stack size form the prompt as I always did in linux before. Thanks for posting this finally had the issue resolved

Wendy Doerner (Intel)'s picture

Bob, This comment field is not for technical support. It would be best to report this with a test case to or on our forums at The number you give to heap-arrays determines what size arrays get put on the heap. With no number or 0 all temporary or automatic arrays are put in the heap. - Wendy

BABAK's picture


In a very small program when I debug the program with the "Heap Array" being without a number or with number '0' there is no problem. But when in my large program which consists of subroutines with large-size ARGUMENT arrays, when the "Heap Array" is blank I get an error about stack overflow. As I have read through other threads one way is to change the "Heap array " number to '0' to solve this problem. But when I do so my output would only be 'NaN'. I don't know how to solve this problem.
BUT when I run my large program without SUBROUTINES I do not get any error with stack overflow when the "Heap Array" is blank. But when I change the "heap array" to '0' or '25' I again get "NaN" .

How can I solve this problem?


anonymous's picture


Wendy Doerner (Intel)'s picture

We put some arrays on the stack for performance reasons. (It is faster to access them from stack). You can always use -heaparrays if you want to put them in the heap (at performance loss). It is a tradeoff you get to make.

anonymous's picture

I am implementing some high level parallelism in a production CFD code, by
calling big subroutines form openmp parallel do loop. I have tested the approach
with simple code and find that F0x10000000 is required to to elimanate stack overflow.
i have gone up to 0x100000000 in the production code and still have a problem.
Interestingly the PG Fortran compiler does no require this type of intervention and works
fine for the test case. However PG code is slow compared to Intel both serial and
parallel (likely due to vectorization). I have noticed that many large parallel codes
with OpenMP use PG fortran, probably for this reason. I would like to stick with Intel
but there seems to be no guidance. I am going to buy PG Fortran as well as test Oracale/Sun Fortran

anonymous's picture

I had this problem under Linux with ifort above 10.0, and I used both solutions:
-> the "ulimit -s unlimited" bash option was clearly the best choice for the program I am using, rather than "ifort ... -heap-arrays". I don't know why but it is between 10 and 100 times quicker with ulimit -s unlimited than with -heap-arrays.

Thanks for the solution

Add a Comment

Have a technical question? Visit our forums. Have site or software product issues? Contact support.