- Marcar como novo
- Marcador
- Subscrever
- Silenciar
- Subscrever fonte RSS
- Destacar
- Imprimir
- Denunciar conteúdo inapropriado
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
- Marcar como novo
- Marcador
- Subscrever
- Silenciar
- Subscrever fonte RSS
- Destacar
- Imprimir
- Denunciar conteúdo inapropriado
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 copiado
- Marcar como novo
- Marcador
- Subscrever
- Silenciar
- Subscrever fonte RSS
- Destacar
- Imprimir
- Denunciar conteúdo inapropriado
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
- Marcar como novo
- Marcador
- Subscrever
- Silenciar
- Subscrever fonte RSS
- Destacar
- Imprimir
- Denunciar conteúdo inapropriado
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).
- Marcar como novo
- Marcador
- Subscrever
- Silenciar
- Subscrever fonte RSS
- Destacar
- Imprimir
- Denunciar conteúdo inapropriado
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.
- Marcar como novo
- Marcador
- Subscrever
- Silenciar
- Subscrever fonte RSS
- Destacar
- Imprimir
- Denunciar conteúdo inapropriado
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.
- Marcar como novo
- Marcador
- Subscrever
- Silenciar
- Subscrever fonte RSS
- Destacar
- Imprimir
- Denunciar conteúdo inapropriado
Aha! Now it makes perfect sense.
Thanks a lot for your effort Kevin!

- Subscrever fonte RSS
- Marcar tópico como novo
- Marcar tópico como lido
- Flutuar este Tópico para o utilizador atual
- Marcador
- Subscrever
- Página amigável para impressora