Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Vitaly_V__K_
Beginner
139 Views

icpc 14.0 compiler bug with MIC building

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

[cpp]

#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;
}

[/cpp]

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

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

while it compiles successfully with

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

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

[bash]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;[/bash]

0 Kudos
11 Replies
pbkenned1
Employee
139 Views

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

Vitaly_V__K_
Beginner
139 Views

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

Compiling with the command

[bash]icl /Qmic -o tmp.exe tmp.cpp[/bash]

gets these error messages:

[bash]

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)

[/bash]

Vitaly_V__K_
Beginner
139 Views

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

pbkenned1
Employee
139 Views

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. 

pbkenned1
Employee
139 Views

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

 

 

Vitaly_V__K_
Beginner
139 Views

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.

139 Views

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_
New Contributor I
139 Views

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

John_F_1
Beginner
139 Views

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.

pbkenned1
Employee
139 Views

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

pbkenned1
Employee
139 Views

>>>It will never be fixed for KNC by addressing the root cause (a gcc defect) by updating the MPSS with something newer.

I should retract this, as the latest version of MPSS 3.6.1 (for KNC) has a much newer gcc:

[fooboyz]$ /opt/mpss/3.6.1/sysroots/x86_64-mpsssdk-linux/usr/bin/k1om-mpss-linux/k1om-mpss-linux-cpp --version
k1om-mpss-linux-cpp (GCC) 5.1.1
Copyright (C) 2015 Free Software Foundation, Inc.

So, this test case now compiles for native KNC and runs there normally:

[fooboyz]$ cat shared_ptr_mmic.cpp
#include <memory>
#include <iostream>
using namespace std;

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);
 std::cout << "\n on MIC, *some_num = " << *some_num << std::endl;
 return 0;
}

[fooboyz]$ icc -V
Intel(R) C Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0.1.141 Build 20151021
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

[fooboyz]$ icc -std=gnu++0x shared_ptr_mmic.cpp -mmic -o shared_ptr_mmic.exe
[fooboyz]$ /usr/bin/micnativeloadex shared_ptr_mmic.exe

 on MIC, *some_num = 1

[fooboyz]$

Patrick

 

Reply