On 07/15/15 04:42, Ilya Verbin wrote:
2015-07-15 2:59 GMT+03:00 Nathan Sidwell <nat...@acm.org>:
The other thing this does is change the interface between libgommp and the plugin's 
load_image and unload_image routines.  I've added the ability to return a pointer to 
target-specific connection data, and have it provided to the unload function.  The ptx 
routines allocate some storage during loading, but had no way to free it on onloading. 
(Actually, the unloading was rather broken, attempting to free the wrong thing.)  this 
data is stashed in the map created for host->target fns & vars.

Why do you need to return dev_data to libgomp?  Is it possible to save
it in plugin, e.g. in some global set with target_data as a key?  I've
implemented unloading this way in plugin-intelmic.

Ok.  The thought occured to me too late :)


@@ -350,11 +350,11 @@ generate_host_descr_file (const char *ho
     "#ifdef __cplusplus\n"
     "extern \"C\"\n"
     "#endif\n"
-   "void GOMP_offload_register (void *, int, void *);\n"
+   "void GOMP_offload_register (void *, int, const void *);\n"
+   "void GOMP_offload_unregister (void *, int, void const *);\n"
     "#ifdef __cplusplus\n"
     "extern \"C\"\n"
     "#endif\n"
-   "void GOMP_offload_unregister (void *, int, void *);\n\n"

I haven't tried to build intelmic-mkoffload, but looks like here is
something wrong with extern "C".

Doh! I'd misread the idiom as using the { ... } form.

nathan

Reply via email to