Community
cancel
Showing results for 
Search instead for 
Did you mean: 
mycroftholmes
Beginner
106 Views

catastrophic errors in icl for mac/win

Hi all,
we are currently evaluating the intel compiler, we installed both in vs2008sp1 and in XCode on a mac.
we have an admittedly complex command line project that instantiates a lot of templates; the source code is rigorous standard c++ and it works fine in any visual studio and in any gcc.
In fact the intel compiles the project just fine but:
1) on the mac, if we compile for x86-64, we cannot start the executable: it constantly crashes on one of the first lines that is more or less like:
void f(const char* p)
{
switch (*(p++)) // <--- crashes here
{
// later
std::string s = "ABC";
f(s.c_str());
if we compile a 32 bit executable, instead, it works perfectly but ONLY IN THE DEBUGGER.
when we run the program from the terminal, we just get a segmentation fault message
2) on windows, even worse: the compilation randomly stops at some point, mentioning the destructor of a class and saying something like "catastrophic failure: unable to obtain mappedmemory(see pch_diag.txt)".
I said "randomly" because that depends on the compilation settings. if we change, say, some linker property, then the compiler error disappears and instead we get a linker crash.
the bugs on windows do not worry me too much. any suggestion about the mac?
0 Kudos
4 Replies
Quoc-An_L_Intel
Employee
106 Views

This might be the same issue reported here.

http://software.intel.com/en-us/forums/showthread.php?t=74791

It is a known issue with the linker from xcode 3.2.2. It incorrectly resolves relocations against symbols which name start with 'L' character. The same object files, being linked with a previous linker (from 10.5.8) works fine on any version of macOS, including 10.6.3.

We are working on a fix in the compiler to work around this linker problem. Could you try Xcode 3.2.1 instead?

An

mycroftholmes
Beginner
106 Views

Unfortunately we have a single mac, with 10.6.4 and xcode 3.2.2

if I read correctly, the issue above is the opposite: an x64 executable never works, an x86 executable launched in gdb inside xcode works, andthe same x86 executable launched in terminal crashes.

further, we tried a smaller project that includes roughly the same headers, and it crashes on the very same line, with EXC_BAD_ACCESS.

anyway, the very same code gives different (but catastrophic) errors in the windows version too: if we disable completely interprocedural optimizations (which in the standard debug configuration are active?) and we disable completely precompiled headers, we get a linker crash, stating that a particular module has corrupt debug information. recompiling that module apparently works, but anyway we cannot link, so we cannot test if this mac crash also appears in windows.

mecej4
Black Belt
106 Views

You have described some symptoms of a problem that could have multiple causes. Had someone reading this forum seen the same symptoms, you could expect to have heard from them.

Since that has not happened, it may be the case that you are reporting a new bug in the compiler. Or, the bug may be in your code. To proceed, we need a test case with which we can reproduce the problem.

Quoc-An_L_Intel
Employee
106 Views

This issue is resolved with the latest update of Intel Parallel Composer 2011 or Composer XE products.
Reply