- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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;
}
}
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
std::vector
bad_func();
#pragma omp parallel for
for(unsigned int q=0; q<8; ++q) {
std::vector
}
}
catch(std::exception& e) {
std::cerr << e.what() << std::endl;
}
}
Link Copied
4 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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;
}
}
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
std::vector
bad_func();
#pragma omp parallel for
for(unsigned int q=0; q<8; ++q) {
std::vector
}
}
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!!!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page