Using icpc as follows (version 15.0.0 20140530 on Ubuntu 14.04)
icpc -std=c++11 <file> -o <out> -O0
for the following code, yields an executable that segfaults (backtrace following the code, core file attached). This does not occur in g++ or clang++. Yes the lambda does not do anything, but that is not the point, this is a simplification of real code that isolates the problem. There seems to be an issue with the generated code versus the copy semantics for std::shared_ptr.
As an aside, what is the status for using Clang with Xeon Phi cards? We are developing c++11 code to run across x86_64 and MIC and would _much_ rather just use Clang for both.
#include <string> #include <iostream> #include <memory> using namespace std; struct S { shared_ptr<string> s; S(string *s) : s{s} {} }; S meh() { S c{new string("meh")}; auto l = [c]() -> void{ cout << c.s << endl; }; return c; } int main() { S s = meh(); return EXIT_SUCCESS; }
#0 0x0000000000400e01 in _INTERNAL_27_lambda_capture_by_value_cxx_7c66d640::__gnu_cxx::__atomic_add_single(int*, int) ()
#1 0x0000000000400e9d in _INTERNAL_27_lambda_capture_by_value_cxx_7c66d640::__gnu_cxx::__atomic_add_dispatch(int*, int) ()
#2 0x0000000000401243 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_add_ref_copy() ()
#3 0x000000000040138b in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::__shared_count(std::__shared_count<(__gnu_cxx::_Lock_policy)2> const&) ()
#4 0x00000000004014fd in std::__shared_ptr<std::string, (__gnu_cxx::_Lock_policy)2>::__shared_ptr(std::__shared_ptr<std::string, (__gnu_cxx::_Lock_policy)2> const&) ()
#5 0x0000000000401523 in std::__shared_ptr<std::string, (__gnu_cxx::_Lock_policy)2>::__shared_ptr(std::__shared_ptr<std::string, (__gnu_cxx::_Lock_policy)2> const&) ()
#6 0x00000000004016af in std::shared_ptr<std::string>::shared_ptr(std::shared_ptr<std::string> const&) ()
#7 0x00000000004010a7 in S::S(S const&) ()
#8 0x0000000000400f90 in meh() ()
#9 0x0000000000400fe8 in main ()
~ ry