- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi!
I have this code:
//#include <string> #pragma offload_attribute (push, target(mic)) #include <algorithm> #include <numeric> #pragma offload_attribute (pop) int main() { #pragma offload target(mic) { int a[10] = {0,1,9,2,8,3,7,4,6,5}; int b[10]; std::iota(b, b+10, 0); std::sort(b, b+10, [&](int i, int j){ return a < a; }); } return 0; }
The code compiles ok, except when I uncomment the "#include <string>". In this case I get a ton of undefined references.
Can anybody tell me why?
Thanks,
Martijn
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Our Developers clarified what happens in your case.
<string> includes other header files which are needed on the target; however, header files are protected by #ifdef to prevent multiple reads. Thus, its inclusion before the push/pop causes some header files to not get included again even though they are included later from within the push/pop, this leads to the numerous undefined references.
The proper change is to move the <string> inclusion line to after the push/pop, and then the code will compile cleanly.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Some extra info might be a good idea.
On a CentOS 7 box I'm running "icc -std=c++11 myfile.cpp -o i &> output.txt". The resulting output.txt is attached to this post.
My Xeon Phi 7120 seems to be setup correctly, I get the expected results when I compile and run the examples from chapter 2 from the Jeffers/Reinders "Intel Xeon Phi Coporocessor High Performance Programming" book.
"icc --version" results in "icc (ICC) 16.0.1 20151021".
Thanks,
Martijn
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is a confusing aspect of the offload programming model and one that still confuses me. I gave a basic explanation below but will ask our more expert C/C++ developers to chime in soon.
Essentially, in the absence of the offload_attribute push/pop pragmas, the specified includes do not have the corresponding function prototypes decorated for use in offloaded code; therefore, when those functions appear in offloaded code an instance is not available during the offload link and this results in an undefined reference (or many undefined references as in your case).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm working with Developers to understand this behavior, and I'm not sure whether you discovered this already, but if you include <string> within the scope of the offload_attribute push/pop then the test case will compile/link successfully.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Our Developers clarified what happens in your case.
<string> includes other header files which are needed on the target; however, header files are protected by #ifdef to prevent multiple reads. Thus, its inclusion before the push/pop causes some header files to not get included again even though they are included later from within the push/pop, this leads to the numerous undefined references.
The proper change is to move the <string> inclusion line to after the push/pop, and then the code will compile cleanly.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aha! Now it makes perfect sense.
Thanks a lot for your effort Kevin!

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