[all-commits] [llvm/llvm-project] 5ba8ec: [Clang][OpenMP] Find the type `omp_allocator_handl...

[Shilei Tian via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 5ba8ecb6cc7b76e7124566e53a3bce9393763a20
      https://github.com/llvm/llvm-project/commit/5ba8ecb6cc7b76e7124566e53a3bce9393763a20
  Author: Shilei Tian <i at tianshilei.me>
  Date:   2023-01-24 (Tue, 24 Jan 2023)

  Changed paths:
    M clang/lib/Sema/SemaOpenMP.cpp
    A clang/test/OpenMP/bug54082.c
    M clang/test/OpenMP/target_uses_allocators.c
    A openmp/runtime/test/parallel/bug54082.c

  Log Message:
  -----------
  [Clang][OpenMP] Find the type `omp_allocator_handle_t` from identifier table

In Clang, in order to determine the type of `omp_allocator_handle_t`, Clang
checks the type of those predefined allocators. The first one it checks is
`omp_null_allocator`. If the language is C, and the system is 64-bit, what Clang
gets is a `int`, instead of an enum of size 8, given the fact how we define
`omp_allocator_handle_t` in `omp.h`.  If the allocator is captured by a region,
let's say a parallel region, the allocator will be privatized. Because Clang deems
`omp_allocator_handle_t` as an `int`, it will first cast the value returned by
the runtime library (for `libomp` it is a `void *`) to `int`, and then in the
outlined function, it casts back to `omp_allocator_handle_t`. This two casts
completely shaves the first 32-bit of the pointer value returned from `libomp`,
and when the private "new" pointer is fed to another runtime function
`__kmpc_allocate()`, it causes segment fault. That is the root cause of PR54082.
I have no idea why `-fno-pic` could hide this bug.

In this patch, we detect `omp_allocator_handle_t` using roughly the same method
as `omp_event_handle_t`, by looking it up into the identifier table.

Fix #54082.

Reviewed By: ABataev

Differential Revision: https://reviews.llvm.org/D142297