openmp/exception handling bug on Intel C++

[marcusexoticmatter_c]

Hello,

I have boiled down a complex "bug" into a very small program which fails to catch an exception when compiled by the Intel C++ compiler (v11), however it works fine on gcc (4.x). Note that on the Intel compiler, it doesn't crash, it just sits there forever. When I ran it through gdb I noticed it seemed to be going into an endless loop in the std::vector destructor (see the code below).

What triggers this bug seems to be the inclusion of the OpenMP parallel directive. If I serialize the little loop by commenting out the #pragma omp parallel for, the exception is succesfully caught, even on the Intel compiler. So it seems to have something to do with the Intel compiler's OpenMP implementation, and how it plays with exceptions. It is a compiler bug, I think, since this code doesn't throw any exceptions inside the parallel region. Please see below:


#include
#include
#include

std::string
bad_func()
{
throw std::exception();
}

int
main(int argc, char* argv[])
{
try {
std::vector v0;
std::vector v1;
bad_func();
#pragma omp parallel for
for(unsigned int q=0; q<8; ++q) {
std::vector u,v;
}
}
catch(std::exception& e) {
std::cerr << e.what() << std::endl;
}
}

[Michael_K_Intel2]

Quoting - marcusexoticmatter.com

Hello,

I have boiled down a complex "bug" into a very small program which fails to catch an exception when compiled by the Intel C++ compiler (v11), however it works fine on gcc (4.x). Note that on the Intel compiler, it doesn't crash, it just sits there forever. When I ran it through gdb I noticed it seemed to be going into an endless loop in the std::vector destructor (see the code below).

What triggers this bug seems to be the inclusion of the OpenMP parallel directive. If I serialize the little loop by commenting out the #pragma omp parallel for, the exception is succesfully caught, even on the Intel compiler. So it seems to have something to do with the Intel compiler's OpenMP implementation, and how it plays with exceptions. It is a compiler bug, I think, since this code doesn't throw any exceptions inside the parallel region. Please see below:


#include
#include
#include

std::string
bad_func()
{
throw std::exception();
}

int
main(int argc, char* argv[])
{
try {
std::vector v0;
std::vector v1;
bad_func();
#pragma omp parallel for
for(unsigned int q=0; q<8; ++q) {
std::vector u,v;
}
}
catch(std::exception& e) {
std::cerr << e.what() << std::endl;
}
}

Hi!

I have tried the program both with GCC 4.3.2 and ICC 11.1 20090630 and it worked for both compilers. Can you be more specific, which version of ICC causes the problem. That would make it much easier to track down the problem.

Cheers
-michael

[marcusexoticmatter_c]

Quoting - Michael Klemm, Intel

Hi!

I have tried the program both with GCC 4.3.2 and ICC 11.1 20090630 and it worked for both compilers. Can you be more specific, which version of ICC causes the problem. That would make it much easier to track down the problem.

Cheers
-michael

Hi Michael,
Thanks for your post.

This is the exact command-line invocation I am using for the intel C++ compiler (icpc) :

$ icpc -fexceptions -Wall -fPIC -pipe -fno-common -g3 -O0 -openmp -openmp-report2 main.cc

where 'main.cc' is a text file containing the code I posted.

The resulting 'a.out' binary never returns, being stuck inside the ~vector destructor. HOWEVER: I just noticed the problem goes away if I specify -O1..3 instead of -O0. very bizarre!!!

[marcusexoticmatter_c]

Quoting - Michael Klemm, Intel

Hi!

I have tried the program both with GCC 4.3.2 and ICC 11.1 20090630 and it worked for both compilers. Can you be more specific, which version of ICC causes the problem. That would make it much easier to track down the problem.

Cheers
-michael

I am using icpc (ICC) 11.1 on 64-bit Linux (Fedora 11) btw.

And the problem still does occur with -O1..3 in another program that does the same thing :(
However, on the code I posted, please do compile with -O0 so that the bug occurs.

thanks
Marcus

[Michael_K_Intel2]

Quoting - marcusexoticmatter.com

I am using icpc (ICC) 11.1 on 64-bit Linux (Fedora 11) btw.

And the problem still does occur with -O1..3 in another program that does the same thing :(
However, on the code I posted, please do compile with -O0 so that the bug occurs.

thanks
Marcus

Hi!

I've tried your command line options and they make the program hang. I have played around with the options and found out that -O0 or -g3 has to be present to trigger the bug. If you remove both of them, the compiler creates a functional executable. Maybe this you can use this as a work-around for now until one of the compiler guys was able to take a closer look at the problem.

Cheers,
-michael