Mapped without a warning, but device code fails at run time

Hi,
By checking the compiler message, a type is mapped without triggering
a Non-trivial type … warning, but the device code fails at the run time leaving:

Libomptarget fatal error 1: failure of target construct while offloading is mandatory

(in the code accessing an element in a user-defined “vector”)
in this case, should I worry about a possible compiler bug?

Hi Itaru, yes, this is possible, unlees you're trying to map a pointer in your "vector" type.

Best regards,
Alexey Bataev

This can have various reasons, including a compiler bug.
Try to enable debug messages by the runtime and see if that helps to determine why offloading failed.
You can also provide a small reproducer so we can take a look.

Hi,
How do I enable debug messages at run time?
I’ve attached a small reproducer for you to take a look at it.

my1.cpp (1.55 KB)

I think:
  export LIBOMPTARGET_DEBUG=1
and
  export LIBOMPTARGET_DEVICE_RTL_DEBUG=1
when you build the openmp runtime with debug support,
so when LIBOMPTARGET_ENABLE_DEBUG is set in cmake.

I don't have a setup to test your program right now but I hope someone else can.

Johannes, all,

Do you have a sample code that shows descriptive debug messages? In my codes, I don’t see any tailored messages other than usual errors.

I don't know what you mean by descriptive debug messages compared to "the usual errors".
Can you share what you see for the example you have problems with?

I was expecting if the app was built with debug clang and appropriate env vars are set prior to its run, I should be getting more than a line
like:

Libomptarget fatal error 1: failure of target construct while offloading is mandatory

Check that you’re using the debug version of libomptarget. Maybe, need to change LD_LIBRARY_PATH.

Best regards,
Alexey Bataev

In the installed lib directory, there’s only libomptarget.so. Assuming the debug version has a different
file name.

In the attached code, if I remove the protected member, syn_id_delay_ from the class definition, it runs on the device.

This sounds like a bug. Changing a type should not only impact runtime
offloading behavior (with exceptions).

I fail to locate the attachment, could you resend or put it somewhere
online?

Thanks,
  Johannes

Got it this time (attached again for the list), thanks!

After a brief look, I think we need to open a bug for this. If the behavior is as you described, it is a problem we need to fix.

my1.cpp (1.55 KB)

I rather doubt there is a bug in the compiler. The code maps the pointer and then tries to call a member function using this pointer. It will work only with unified memory, I think. If the program does not rely on the unified memory, the program is not correct, since it doea not offload the data itself.

Best regards,
Alexey Bataev

Alexey,
I changed the program so the data are offloaded to the device and worked. However, the stack is limited so
in my application of interest, this limitation means I have to run my app with a very limited number of neurons.

Is the current implementation of OpenMP supposed to work well with hardware that supports unified memory?

As far as I know, unified memory is fully supported. You can try to use it.

Best regards,
Alexey Bataev

Alexey,

A change like this:

map(to: c[0:1]), here c is a pointer

made the program run on the device. We’re inspired about this from page 32 of the presentation:
https://ukopenmpusers.co.uk/wp-content/uploads/uk-openmp-users-2018-OpenMP45Tutorial_new.pdf

Yes, this looks like as more correct solution though there might be some problems with deep copy mapping of inner pointers in the structure.

Best regards,
Alexey Bataev