Software Archive
Read-only legacy content
17061 Discussions

issues with offload and #include <string>

MSand23
Beginner
330 Views

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
330 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

0 Kudos
5 Replies
MSand23
Beginner
332 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
 

 

 

 

0 Kudos
Kevin_D_Intel
Employee
332 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).

0 Kudos
Kevin_D_Intel
Employee
332 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.

0 Kudos
Kevin_D_Intel
Employee
331 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.

0 Kudos
MSand23
Beginner
332 Views

Aha! Now it makes perfect sense.

Thanks a lot for your effort Kevin!

0 Kudos
Reply