icpc 14.0 compiler bug with MIC building

icpc 14.0 compiler bug with MIC building

We try to compile the following source code for Xeon Phi:

#include <memory>
void some_func(const std::shared_ptr<int> &some_num)

	{

	std::shared_ptr<int> num = some_num;

	}
int main()

	{

	std::shared_ptr<int> some_num(new int(1));

	some_func(some_num);

	return 0;

	}

Command line:
Error appears during the compilation with the following command line:

/opt/intel/composer_xe_2013_sp1.0.080/bin/intel64/icpc -mmic -std=gnu++0x -o test.o -c test.cpp 

while it compiles successfully with

/opt/intel/composer_xe_2013_sp1.0.080/bin/intel64/icpc -std=gnu++0x -o test.o -c test.cpp 
(without -mmic flag).

shared_ptr<T> should have ctor from const shared_ptr<T>&, but we get the next error message:

error: function "std::shared_ptr<_Tp>::shared_ptr(const std::shared_ptr<int> &) [with _Tp=int]" (declared implicitly) cannot be referenced -- it is a deleted function

	std::shared_ptr<int> num = some_num;

11 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Thanks for reporting this. I have reported to compiler engineering as defect DPD200248964.  I'll keep this thread updated with any news.

By the way, the same code has compilng error with Intel C++ Compiler for Windows and /Qmic compiler flag.

Compiling with the command

icl /Qmic -o tmp.exe tmp.cpp

gets these error messages:

Intel(R) C++ Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 14.0.0.103 Build 20130728
Copyright (C) 1985-2013 Intel Corporation. All rights reserved.
tmp.cpp(5): error #303: explicit type is missing ("int" assumed)
 void some_func(const std::shared_ptr<int> &some_num)
 ^
tmp.cpp(5): error: qualified name is not allowed
 void some_func(const std::shared_ptr<int> &some_num)
 ^
tmp.cpp(5): error: expected a ")"
 void some_func(const std::shared_ptr<int> &some_num)
 ^
tmp.cpp(7): error: namespace "std" has no member "shared_ptr"
 std::shared_ptr<int> num = some_num;
 ^
tmp.cpp(7): error: type name is not allowed
 std::shared_ptr<int> num = some_num;
 ^
tmp.cpp(7): error: identifier "num" is undefined
 std::shared_ptr<int> num = some_num;
 ^
tmp.cpp(7): error: identifier "some_num" is undefined
 std::shared_ptr<int> num = some_num;
 ^
tmp.cpp(11): error: namespace "std" has no member "shared_ptr"
 std::shared_ptr<int> some_num(new int(1));
 ^
tmp.cpp(11): error: type name is not allowed
 std::shared_ptr<int> some_num(new int(1));
 ^
tmp.cpp(11): error: identifier "some_num" is undefined
 std::shared_ptr<int> some_num(new int(1));
 ^
tmp.cpp(12): error: argument of type "<error-type> (*)(...)" is incompatible with parameter of type "int"
 some_func(some_num);
 ^
compilation aborted for tmp.cpp (code 2)

... And I tried to add the compile flags /Qstd:c++11 or /Qstd:c++0x but nothing changes.

The issue is due to the old GCC headers in /usr/linux-k1om-4.7/x86_64-k1om-linux/include/c++.  It is planned to be fixed in a future update to MPSS that includes GCC 4.7.3 (or later), which contains newer headers with the fix. 

For completeness, just providing a few additional details.  The compilation fail is due to a defect in the GNU 4.7.0 C++ standard library, which was fixed in GNU 4.7.1.  The fix is described here: http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01665.html

A good description of the problem (note the resolution of the change in the header) is here:  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53654

 

 

Thank you, Patric.

We have made the change in the header as it said here http://gcc.gnu.org/ml/libstdc++/2012-01/msg00017.html

and the problem has resolved.

Hi Patrick,

  We are having the same issue i.e. old gcc headers are picked up from /usr/linux-k1om-4.7/x86_64-k1om-linux/include/c++. Any update on this?

Alastair M.'s picture

Hi Patrick,

I have just encountered this issue with MPSS 3.2.1.  Is this fixed in any later revisions of MPSS?

Best regards,

Alastair

This bug still exists in MPSS 3.4. I suspect it might be some time before they update the version of GCC used by MPSS. However, the workaround posted by Vitaly above (http://gcc.gnu.org/ml/libstdc++/2012-01/msg00017.html) still works with MPSS 3.4.

This issue should be fixed via a compiler workaround in the next update, 15.0.2.  It will never be fixed for KNC by addressing the root cause (a gcc defect) by updating the MPSS with something newer.  However, the next generation Xeon Phi coprocessor (Knight's Landing) will contain gcc 4.7.3 or later in its MPSS, and this will be a non-problem.

Patrick

Login to leave a comment.