Community
cancel
Showing results for 
Search instead for 
Did you mean: 
MSand23
Beginner
105 Views

issues with offload and #include <string>

Jump to solution

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

 

0 Kudos
1 Solution
Kevin_D_Intel
Employee
105 Views

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.

View solution in original post

5 Replies
MSand23
Beginner
105 Views

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
 

 

 

 

Kevin_D_Intel
Employee
105 Views

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).

Kevin_D_Intel
Employee
105 Views

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.

Kevin_D_Intel
Employee
106 Views

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.

View solution in original post

MSand23
Beginner
105 Views

Aha! Now it makes perfect sense.

Thanks a lot for your effort Kevin!

Reply