Segmentation fault from program_options with intel compiler and openmp

[Ryan Scott Davis <rsdavis@…>]

When using program_options to parse the command line, a segmentation fault results from the store() function after a call to parse_command_line(). This seems to only happens when using the -openmp flag with the intel c++ (icpc) compiler (version 11) and -openmp compiler directive.

[Ryan Scott Davis <rsdavis@…>]

minimal, complete example

[Ryan Scott Davis <rsdavis@…>]

Sorry, apparently this is some weird linking error. For others, I was compiling with

icpc -L /path/to/boost/lib -I /path/to/boost/include test.cpp -static -lboost_program_options -openmp

which compiled fine but result in seg fault. I guess older libraries on the cluster were somehow being linked. Instead, I now link to the library file directly, and it works, magic.

icpc -I /path/to/boost/include test.cpp /path/to/boost/lib/libboost_program_options.a -openmp

[anonymous]

I see something similar with gcc4.7 and boost 1.49.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff772b427 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt
#0  0x00007ffff772b427 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x0000000000b04229 in std::_Rb_tree_iterator<std::string>::operator-- (this=0x7fffffffd7a0)
    at /usr/include/c++/4.7/bits/stl_tree.h:203
#2  0x0000000000aedba8 in std::_Rb_tree<std::string, std::string, std::_Identity<std::string>, std::less<std::string>, std::allocator<std::string> >::_M_insert_unique<std::string const&> (this=0x10aab10, __v=...)
    at /usr/include/c++/4.7/bits/stl_tree.h:1295
#3  0x0000000000ad6d3f in std::set<std::string, std::less<std::string>, std::allocator<std::string> >::insert (
    this=0x10aab10, __x=...) at /usr/include/c++/4.7/bits/stl_set.h:415
#4  0x0000000000cf00dd in boost::program_options::store (options=..., xm=..., utf8=false)
    at libs/program_options/src/variables_map.cpp:98
#5  ...

I need to do some more investigation but this code has worked fine in gcc 4.6 and with boost 1.47.

Jamie

[ja11sop@…]

See also ​http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53490

[Vladimir Prus]

Per discussion in gcc bugzilla, the gcc problem is due to mismatched compilation options, and is independent from original intel problem.

I am changing back the severity.