out of memory

[Roe_Z_]

Hello,

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?

Thanks

[TimP]

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.

[Roe_Z_]

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.

flags:

CC = icc

FC = ifort

LDFLAGS = -lstdc++

CFLAGS = -O2

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

[TimP]

-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.

[Martyn_C_Intel]

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.