Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.
The Intel sign-in experience has changed to support enhanced security controls. If you sign in, click here for more information.
7782 Discussions

FATAL ERROR - ICC generates dysfunctional code on OSX 32-bit (plus ICC crashes when compiling debug version)


I use ICC on Windows and OSX. On Windows everything is fine. On OSX my project (release version) compiles just fine on 64-bit architecture. But on 32-bit it creates a malfunctioning code that crashes with a call stack containing a single line, saying that it crashed in operator delete(void*, void*). Note, it's the same code (except system services of course) on Windows 32 & 64 and Mac 32 & 64 and ONLY Mac 32 doesn't work. I'm having everything up to date (XCode, OSX, ICC), ICC is called from commandline.

So after 2 days of investigating (!!!), because Intel compiler on OSX is about 10x slower than LLVM (!!!) and it's a huge project I found out this: By adding a piece of code, which is neved called during the execution, ICC generates something that crashes in some completely different place. Hard to say where, because: ICC crashes if I try to build a debug version with this:

mcpcom(30826,0xa0cc61d4) malloc: *** mach_vm_map(size=2101248) failed (error code=3)

*** error: can't allocate region

*** set a breakpoint in malloc_error_break to debug

Fatal compilation error: Out of memory asking for 2097160.


When the project is compiled with LLVM it takes 10x less time and it seems working without problems... and it's slower... But mainly this brings up a question - If a code can get malfunctioning like this, how much we can actually trust Intel compiler?? What if the 64-bit code is buggy as well, I just didn't find out yet?

Anyway my guess is that it's some 32-bit specific addressing issue caused by the code being too big. But it's just a wild guess. Anyway it's a dylib and here's the relevant part of command line for compiler:

icpc -fno-rtti -arch i386 -restrict -msse2 -fPIC -shared -I/Applications/ -I/opt/intel/composer_xe_2015/ipp/include -I/opt/intel/composer_xe_2015/ipp/include -I/Applications/ -I/opt/intel/composer_xe_2015.3.187/compiler/include -I. -c -fexceptions -fvisibility=hidden -fpascal-strings -fasm-blocks -stdlib=libstdc++ -mfpmath=sse -Wno-trigraphs -Wno-missing-field-initializers -Wno-missing-prototypes -Wreturn-type -Wno-non-virtual-dtor -Wno-delete-non-virtual-dtor -Wno-overloaded-virtual -Wno-exit-time-destructors -Wformat -Wno-missing-braces -Wparentheses -Wno-switch -Wno-unused-function -Wno-unused-label -Wno-unused-parameter -Wno-unused-variable -Wno-unused-value -Wuninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-sign-compare -Wshorten-64-to-32 -Wno-newline-eof -Wno-deprecated-declarations -Winvalid-offsetof -Wno-conversion -Wno-sign-conversion -Wno-comment -Wno-tautological-compare -Wno-constant-logical-operand -Wno-deprecated-writable-strings -Wno-c++11-extensions -Wno-unnamed-type-template-args -Wno-#pragma-messages -fp-model fast=1 -fno-stack-security-check -std=c++11 -O2 -ipo -ansi-alias -ftz -axAVX -opt-report0 -vec-report0 -isysroot /Applications/ -mmacosx-version-min=10.5

And here's for the linker:

icpc -static-intel -arch i386 -isysroot /Applications/ -Wl,-syslibroot,/Applications/ -mmacosx-version-min=10.5 -shared -dynamiclib -read_only_relocs suppress -L/opt/intel/composer_xe_2015/ipp/lib -L/Applications/ -lipps -lippvm -lippcore -lippi -L/opt/intel/composer_xe_2015.3.187/compiler/lib -framework Carbon -framework Cocoa -framework AudioUnit -framework CoreAudio -framework CoreMIDI -framework CoreServices -framework AudioToolbox -framework IOKit -framework Security -framework OpenGL -framework AGL -Xlinker -headerpad -Xlinker 578 -Wl,-no_compact_unwind -fdata-sections




0 Kudos
2 Replies

Hi meldaproduction,

Let's look at the issues one by one.  Regarding the runtime issue (ICC generates dysfunctional code), it may take you and us some more time to figure out what was wrong.  Need access to source code.

Regarding the second issue (ICC crashes when compiling debug version), It looks that icc was trying to allocation too much memory.  Did this error occur at compilation or linking?  I'm assuming it happened at linking, because IPO is turned on.  Could you please confirm this?



Hi, as I noted in the other thread, I cannot share the source codes, so it will just have to stay like this. I have no reports of 64-bit problems so far, so hopefully that one works...

And I actually don't know with the debug version, because that one doesn't have -ipo enabled. The mentioned command lines are for release version. Sorry I cannot try, already spend days with it and each compilation takes like 10x more time than LLVM, so well, a lot...