out of memory

out of memory


I'm having an error:

Fatal compilation error: Out of memory asking for 1844674404787878768456.

This only happen when compailing with debug flags.

ifort 13.1.0

linux: centos 6.4 64bit kernel 2.6.32-358.el6.x86_64


Any body know this error or which flag can cause it?



5 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

You didn't indicate which flags you used, which phase of compilation, or even confirm whether you are compiling for intel64.

I suppose you are compiling a large application with a single compile command.

I'm not certain whether -ipo might be used along with -debug or -g, as I haven't tried it, and would avoid it in a situation such as this.

When compiling many procedures in a single command with debug and -O options, -fno-inline-functions would avoid some memory-consuming optimizations.

Hi TimP,

Thanks for the replay. I will add here the flags. Hope it will help and maybe you will recognize a flag that is known to cause this problem.

When I run this without the debug its ok.


CC = icc

FC = ifort

LDFLAGS = -lstdc++



debug FLAGS = \

-save \

-u \

-r8 \

-extand_source \

-axSSE4.2 \

-fpconstant \

-implicitnone \

-align all \

-assume nosource_include \

-align dcommons \

-real_size 64 \

-common_args \

-vms \

-override-limits \

-heap-arrays \

-global-hoist \

-reentrancy  -threads \

-mtune=core2 \

-mp1 \

-no-prec-div \

-fno-math-errno \

-finline-limit = 1000 \

-finline-functions \

-inline-factor=1000 \

-inline-forceinline \

-inline-level=2 \

-inline-max-per-routine=1000 \

-O0 \

-fpe0 \

-cpp \

-g -traceback \

-noerror_limit \

-check all \

-check bounds \

-no-ftz \

-debug inline_debug_info \

-prec_div \

-debug semantic_stepping \

-debug variable_locations \

-debug-parameters all \

-fp-stack-check \

-check arg_temp_created

-override_limits explicitly disables some of the compiler's efforts to avoid an out-of-memory condition, as does forceinline.  I would expect this to make more difference with higher levels of optimization than -O0.

This adds to my suspicion that you are compiling a large amount of code in a single compile command.  You may need to reduce inline limits.  I suggested earlier not inlining at all.

I doubt you will get any advantage from -axSSE4.2 at -O0.  If you are trying to support Harpertown and newer CPUs, I would have preferred -mSSE4.1. 

-mp1 is an obsolete option, but should not have a bearing on the question you have asked.

You have a terrifying list of debug options there, it may be unrealistic to expect them all to work together seamlessly on a large program without conflict. I would start with a far smaller list, and gradually add more options only if there's a realistic hope that they will be useful.

For example, -threads suggests that you want to build a threadsafe program; in this case, -save may be dangerous, because it makes local scalars static and prevents them from being threadsafe.

I wouldn't use -reentrancy unless you are seriously intending to write re-entrant code.

I agree with Tim's comments on -override_limits; I would not use this switch unless you have seen  diagnostic that suggests it may be necessary.

-r8 makes no sense as a debug switch; your debug program will have different behavior from your release program. -vms is the same; these are both switches that could easily break a program that worked without them.

Likewise, -axsse4.2, which generates processor-dependent code paths, makes little sense as a debug switch. If you want a program that targets 2nd generation Intel Core processors & later, that support SSE4.2, then build with -xsse4.2 (both debug and non-debug).

I could go on, e.g. the inlining switches, but you get the idea. Don't add switches unless you understand what they do and have a positive need for them. A good set to use to start debugging might be

-O0 -fno-inline -no-ip -g -fpe0 -traceback -check -fp-model precise -implicitnone -warn interfaces

If you are going to do interactive debugging, then you could add -debug switches (but you probably wouldn't want -traceback). Once your application is working, you can start to relax these and increase optimization levels.

Leave a Comment

Please sign in to add a comment. Not a member? Join today