remote process, dlopen() failed undefined symbol:

[TimP]

Full message:

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

I don't know why dlopen should be involved.  The source code fragment:

#pragma omp declare target
extern "C" struct {
  double array[2000*2000];
}
cdata_;
#pragma omp end declare target

In the MIC.s file, the cdata_ references look the same as in a working Fortran equivalent.

Compilation with -Wl,-zdefs doesn't produce any messages.

[TimP]

The same failure comes up in a pure Fortran build, when both omp declare target and omp target map are present in the same build.  icc doesn't accept the usage of omp target update in many cases where ifort does, so this looks like a severe limitation on use of C with omp target.    g++ runs my tests correctly (but simulates target by running on host).

 I suppose this may fall in the category of combinations of openmp features which aren't planned for the current compiler.

[TaylorIoTKidd]

Hey Tim,

Given your august BB status, I assume you want me to pass this on to the compiler folk. Correct?

--
Taylor
 

[Ravi_N_Intel]

I don't know why dlopen should be involved

The current compiler creates the MIC binary as a .so and is loaded during offload on MIC using dlopen.

Need more info on how you build and run the program to analyze why cdata_ is not found.

[TimP]

Ravi,

These old posts were somehow pushed to the head of list (some others escaped from moderation jail) when my account was tinkered with yesterday.

As far as I can see, the appearance of a data region symbol which it wants to satisfy as a function reference in dlopen() looks like a bug, or at least it prevents use of target data and target map in the same application in either Fortran or C++.  Patrick Kennedy has made an escalation from my IPS issue. 

I don't know exactly which aspect is escalated. The original question was on the relative roles of target update and target map and whether both are required to handle both target data and local arrays.

I encountered the issue on KNC C0 before I was moved back to B0.

Thanks,

Tim

[Ravi_N_Intel]

target map becomes a no-op for a variable inside a target data with the same variable.  Need to use target update to sync up data.local arrays should be synced with target map.

If these answers are not addressing the question, then I will wait for Patrick to file a bug to get a better understanding of the question.

[TimP]

Yes, I got the message (not self-explanatory to me from reading the standard) that it's necessary to use target update and not target map to perform updates with target data, but why can't target map be used elsewhere in an application which has target data?  This seems to imply that an application which uses target data can't use any other method for processing data on the coprocessor, but it's not a self-evident restriction, nor one which the compiler diagnoses in a reasonable way.

[Vishal1]

I'm getting a similar error using __atribute__((target(mic))) to mark a function for offload, but only when I link with MKL. Please see http://software.intel.com/en-us/forums/topic/500749 for more details about wat happens in my case.