I compiled the following code with icc12 and it aborts at run-time when
pthread_exit tries to unwind the stack. The cause, as I understand it,
is due to an empty call site table generated by icc12. In contrast,
icc11.1 generates a proper table.
It's my understanding that since it's a global counter, it should be 0 initialized (certainlly in C++ but even in C). But, on the off chance that it wasn't, I tried adding the =0, and it made no difference.
After doing a bit more digging, it looks like the issue is cornered to extern "C". Icc12 assumes that
everything declared as extern "C" will not trigger exception, so skipped
in generating the call site entry for code that calls them.
Om. Thanks very much. I look forward to your update.
Sadly, -O0 doesn't work for us, since we need the compiler optimizations
in the rest of our code, as it's a production system. Fortunately, we
were able to find an alternative workaround:
if we write a trivial c++ wrapper for the functions, without inline or
throw(), it seems icc decides it might generate an exception, and then
everything works properly.
@jimdempseyatthecove - Yes, that's already been tried, and no, it doesn't make a difference. The issue is with pthread_exit, and will occur even if handler_with_guard is not the thread entry point.
This may or may not be a related problem. I have been working on some code on Intel 64 that contains __asm blocks. In release mode the code failed. I noticed that the optimizaton defaulted to IPO enabled. So I thought that there may be a problem with the inlining of a function containing the __asm block. As a guess to the problem I added __declspec(noinline) the the function declaration and the resultant code worked as expected. I know your code does not have an __asm block, However, your code has an unusual exit from the called function (it exits the pthread thread). Try adding __declspec(noinline) the the function declaration.
Do notassume -noinline is equivilent to __declspec(noinline) as IPO may be overly aggressive.