https://bugs.llvm.org/show_bug.cgi?id=46515

            Bug ID: 46515
           Summary: Call abort() instead of exit() on runtime error
           Product: OpenMP
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Runtime Library
          Assignee: unassignedb...@nondot.org
          Reporter: gcc.j.kell...@hzdr.de
                CC: llvm-bugs@lists.llvm.org

While debugging a openmp target usage inside a complex program, I found, that
libomptarget calls exit() when it encounters a runtime error, which in my case
causes a deadlock instead of program termination.

Specifically, I am seeing the error message:
"Libomptarget fatal error 1: failure of target construct while offloading is
mandatory"
after which the program is hangs in a deadlock instead of terminating.

I suggest to change this to call abort() instead of exit(). The rationale is
the situation in the program I an working on.

# Rationale

The program implements a queue to run kernels on backends, one of which is
based on OpenMP target offload. In my case I am using a synchronous queue, in
which case, a function A() calling a function B() containing an omp target
region holds a mutex lock on the queue within its scope (std::lock_guard)
(effectively while B() is executing).

Another component of the program registers the same queue in a global object.
That objects destructor is responsible for clearing destructing the queue
before program termination. Part of this is synchronizing the queue, which
requires the mutex held by A() to be locked.

When exit() is called inside B(), the stack is not unwound, i.e. the lock held
by A() is not released, but the destructors of global objects like that queue
wrapper are called, which causes a dead lock. This could be avoided by calling
abort() on runtime errors instead.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

Reply via email to