topic I'm working with Developers in Software Archive

issues with offload and #include

MSand23 — Fri, 19 Feb 2016 13:28:16 GMT

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

Some extra info might be a

MSand23 — Mon, 22 Feb 2016 11:01:44 GMT

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

This is a confusing aspect of

Kevin_D_Intel — Mon, 22 Feb 2016 13:03:48 GMT

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

I'm working with Developers

Kevin_D_Intel — Mon, 22 Feb 2016 18:10:09 GMT

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.

Our Developers clarified what

Kevin_D_Intel — Mon, 22 Feb 2016 20:19:00 GMT

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.

Aha! Now it makes perfect

MSand23 — Tue, 23 Feb 2016 07:08:26 GMT

Aha! Now it makes perfect sense.

Thanks a lot for your effort Kevin!