Xeon Phi Cilk Offload: problem with libraries

[Elizaveta_G_]

I try to use Cilk_offload on host + Xeon Phi. example.cpp:

#pragma offload_attribute (push, _Cilk_shared)
#include <vector>
#include <string>
#include "offload.h"
#pragma offload_attribute(pop)
         
int main(const int argc, const char *argv[]) {      
    return 0;
}  

Building: icc example.cpp -o example

When I try to run it, I get the following error:

On the sink, dlopen() returned NULL. The result of dlerror() is "/var/volatile/tmp/coi_procs/1/6847/load_lib/iccoutY1s4hB: undefined symbol: pthread_cancel_wrapper"
On the remote process, dlopen() failed. The error message sent back from the sink is /var/volatile/tmp/coi_procs/1/6847/load_lib/iccoutY1s4hB: undefined symbol: pthread_cancel_wrapper
offload error: cannot load library to the device 0 (error code 20)

And if I remove "#include <string>", everything is ok.

I need <vector> and <string> in a complex program where I have the same problem.

What should I do?

[TimP]

When you use the C compiler to link C++ and maybe invoke some cilk without specifying appropriate libraries, annoying things may happen.  Doesn't that sample directory offer hints such as

icpc example.cpp -lcilkrts

?

[Kevin_D_Intel]

I am unable to reproduce that error with the test case as is so perhaps I'm not using the same icc and/or MPSS that you are or it is missing something. Can you tell me the versions of icc and MPSS you have?

I can induce the failure with the 14.0 compiler when adding <iostream> into the push/pop _Cilk_shared block so maybe that's what your larger C++ program also does. From that past instance it was learned that <iostream> cannot be included in the _Cilk_Shared due to the fact the library is not built with _Cilk_shared. That could spell bigger issues to face depending on the needs of the larger complex C++ program.

I don't know how much of your complex C++ program can be shared (even in private with us) or whether you could construct a more complete mock-up that represented the issue, if so we might be able to offer help on getting the program enabled with _Cilk_offload or determine if there are roadblocks to doing that.

[JJK]

Same results here: cannot reproduce using either icc14 or icc15; if I add <iostring> I cannot even compile the code using icc15:

> icpc -o offload3a offload3a.cpp -lcilkrts
/tmp/icpcdZzHxF.o:(.MyoFptrTable.[pthread_cancel_myo_thunk_fptr_$MyoTable]+0x10): undefined reference to `pthread_cancel_wrapper'

[Kevin_D_Intel]

Yes. 15.0 is producing a Linux executable binary for the offload image which by default does not permit undefined references where as 14.0 produces the Linux shared object binary which does and so the undefined reference is not exposed until runtime. With 14.0 (and earlier) you can flush out the undefined reference at link time by adding -z defs to the offload link.

$ icc -V
Intel(R) C Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 14.0.4.211 Build 20140805

$ icc u537189.cpp -offload-option,mic,ld,"-z defs"
/tmp/icczHywsc.o:(.MyoFptrTable.[pthread_cancel_myo_thunk_fptr_$MyoTable]+0x10): undefined reference to `pthread_cancel_wrapper'

[Elizaveta_G_]

I haven't found the symbol 'pthread_cancel_wrapper' in libraries, Google (- anywhere!) And when I've added the following

extern "C" { __attribute__((target(mic))) void pthread_cancel_wrapper() {} }

to my code, it works!

My software:
icc version 13.0.1 from Intel Composer_xe_2013.1.117
mpss version 3.4.1
libc versions:
    on host:  libc-2.11.3.so
    on MIC:   libc-2.14.90.so

I will use this workaround, but the question is - who does generate this symbol?

[Kevin_D_Intel]

Thank you for the clarification. I can reproduce this using the 13.1 compiler and see now that later releases are not triggering the offload compilation or image creation with that test case but adding a simple _Cilk_shared function (like below) is sufficient to trigger the error with later releases.

_Cilk_shared int foo()
{
   return(1);
}

The symbol reference is associated with Virtual Shared model runtime. I will talk with the Developers to better understand this.