[llvm-bugs] [Bug 48885] New: Crash in passing firstprivate args to tasks on Apple M1

[via llvm-bugs]

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

            Bug ID: 48885
           Summary: Crash in passing firstprivate args to tasks on Apple
                    M1
           Product: OpenMP
           Version: unspecified
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Runtime Library
          Assignee: unassignedbugs at nondot.org
          Reporter: jcownie at gmail.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 24420
  --> https://bugs.llvm.org/attachment.cgi?id=24420&action=edit
Simple test code.

Passing threadprivate arguments into a task crashes on the Apple M1 aarch64)
machine.

The attached code demonstrates the problem when compiled with -fopenmp (and no
optimisation; with optimisation it appears to pass, but I think that is because
then the compiler recognises that the firstprivate values are constant and
therefore doesn't bother to pass them!)

$ clang --version
clang version 12.0.0 (https://github.com/llvm/llvm-project.git
975b64b29375cdfb3672fedee4216c6512672fbf)
Target: aarch64-apple-darwin20.2.0
Thread model: posix
InstalledDir: /Users/jcownie/software/clang-12.0.0/arm64/bin

$ clang -fopenmp -g test_taskargs.c
$ lldb ./a.out
(lldb) target create "./a.out"
Current executable set to '/Users/jcownie/PPS_rtl/tests/a.out' (arm64).
(lldb) run
run
Process 72954 launched: '/Users/jcownie/PPS_rtl/tests/a.out' (arm64)
Process 72954 stopped
* thread #5, stop reason = EXC_BAD_ACCESS (code=1, address=0x61502000000)
    frame #0: 0x0000000100003d6c a.out`.omp_task_entry. [inlined]
.omp_outlined.(.global_tid.=4, .part_id.=0x0000000108107ed0,
.privates.=0x0000000108107ee8, .copy_fn.=(a.out`.omp_task_privates_map. at
test_taskargs.c:22), .task_t.=0x0000000108107ec0, __context=0x0000000108107ef0)
at test_taskargs.c:25:24
   22   #pragma omp task firstprivate(tpvar, tpvar2)
   23         {
   24           fprintf (stderr, "In task in thread %d tpvar = %d (should be
42), tpvar2 = %d (should be 84)\n", omp_get_thread_num(),
-> 25                   tpvar, tpvar2);
                               ^
   26           failed = (tpvar != 42) || (tpvar2 != 84);
   27         }
   28       }
Target 0: (a.out) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x0)
  * frame #0: 0x0000000100003d64 a.out`.omp_task_entry. [inlined]
.omp_outlined.(.global_tid.=0, .part_id.=0x0000000108107ed0,
.privates.=0x0000000108107ee8, .copy_fn.=(a.out`.omp_task_privates_map. at
test_taskargs.c:22), .task_t.=0x0000000108107ec0, __context=0x0000000108107ef0)
at test_taskargs.c:25:17
    frame #1: 0x0000000100003d08 a.out`.omp_task_entry.((null)=0,
(null)=0x0000000108107ec0) at test_taskargs.c:22
    frame #2: 0x0000000100141878 libomp.dylib`__kmp_invoke_task(int, kmp_task*,
kmp_taskdata*) + 308
    frame #3: 0x0000000100144c38 libomp.dylib`int __kmp_execute_tasks_64<false,
true>(kmp_info*, int, kmp_flag_64<false, true>*, int, int*, void*, int) + 744
    frame #4: 0x000000010014e308 libomp.dylib`kmp_flag_64<false,
true>::wait(kmp_info*, int, void*) + 596
    frame #5: 0x000000010014c6b8
libomp.dylib`__kmp_hyper_barrier_gather(barrier_type, kmp_info*, int, int, void
(*)(void*, void*), void*) + 800
    frame #6: 0x000000010014c090 libomp.dylib`__kmp_join_barrier(int) + 592
    frame #7: 0x000000010012efd0 libomp.dylib`__kmp_internal_join + 92
    frame #8: 0x000000010012e848 libomp.dylib`__kmp_join_call + 264
    frame #9: 0x0000000100121ff8 libomp.dylib`__kmpc_fork_call + 220
    frame #10: 0x0000000100003b8c a.out`main(argc=1, argv=0x000000016fdff6e0)
at test_taskargs.c:15:1
    frame #11: 0x000000018e1f4f34 libdyld.dylib`start + 4

Note that this may be some issue related to a difference in the way varags
functions are handled by the Apple Aarch64 calling convention  from the way
that they're handled on Linux Aarch64. 

This code compiles and executes correctly on Linux/Aarch64, and on other
architectures (X86_64, ...)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210126/78fce495/attachment.html>