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
When `libomp` is initialized, it creates a temp file in `/dev/shm` to store
registration flag. Some systems, like Android, don't have `/dev/shm`, then this
feature is disabled by the macro `KMP_USE_SHM`, though most Linux distributions
have that. However, some customized distribution, such as the one reported in
https://github.com/llvm/llvm-project/issues/53955, doesn't support it either.
It causes a core dump. In this patch, if it is the case, we will try to create a
temporary file in `/tmp`, and if it still doesn't make it, then we error out.
Note that we don't consider in this patch if the temporary directory has been
set to `TMPDIR` in this patch. If `/tmp` is not accessible, we error out.
Fix#53955.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D142175
GCC doesn't support `-fopenmp-version`, causing test failure if the compiler used
for testing is GCC.
GCC's OpenMP 5.2 support is very limited yet. Disable those tests requiring 5.2
feature for GCC as well.
We might want to take a look at all `libomp` tests and mark those tests that
don't support GCC yet.
Reviewed By: ABataev
Differential Revision: https://reviews.llvm.org/D142173
Distributed barrier was found to cause hangs in some test cases. Found
that a section updating the barrier size was improperly shifted to a
different code section during patching. Restored to original
location, all tests run to completion.
Differential Revision: https://reviews.llvm.org/D141618
The test `openmp/runtime/test/atomic/kmp_atomic_float10_max_min.c` uses a compiler
flag `-mlong-double-80` that might not be supported by all targets. Currently it
requires `x86-registered-target`, but that requirement can be true when LLVM
supports X86 while the actual `libomp` arch is not X86. For example, when LLVM
is built on AArch64 with all targets enabled, `x86-registered-target` can be met.
If `libomp` is built with native target, aka. AArch64, the test will still be enabled,
causing test failure.
This patch only enables the test if the actual target is X86. The actual target
is determined by `LIBOMP_ARCH`.
Fix#53696.
Reviewed By: jlpeyton
Differential Revision: https://reviews.llvm.org/D142172
D91464 introduced verbose tool loading, but the test check only considers Linux.
On macOS, the outputs are totally different, causing the regression afterwards.
This patch simply sets the test to XFAIL on macOS.
Fix#56833.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D142045
This patch fixes the inconsistent task state when hot team is not used.
When the primary thread executes `__kmp_join_call`, it calls `__kmp_free_team`,
where worker threads will get destroyed if not using hot team. The destroy of
worker threads also reset their task state. However, the primary thread's is not
reset. When the next parallel region is encountered, in `__kmp_task_team_sync`,
the task state of thread will be flipped. Since the state of primary thread is not
reset, it is still 1, but all the worker threads will be 0, this leads to the
inconsistent task state, causing those threads are using completely different
task team.
Fix#59190.
Reviewed By: tlwilmar
Differential Revision: https://reviews.llvm.org/D141979
Each time a thread gets a new affinity assigned, it will not
only assign its mask, but also topology information including
which socket, core, thread and core-attributes (if available)
it is now assigned. This occurs for all non-disabled KMP_AFFINITY
values as well as OMP_PLACES/OMP_PROC_BIND.
The information regarding which socket, core, etc. can take on three
values:
1) The actual ID of the unit (0 - (N-1)), given N units
2) UNKNOWN_ID (-1) which indicates it does not know which ID
3) MULTIPLE_ID (-2) which indicates the thread is spread across
multiple of this unit (e.g., affinity mask is spread across
multiple hardware threads)
This new information is stored in th_topology_ids[] array. An example
how to get the socket Id, one would read th_topology_ids[KMP_HW_SOCKET].
This could be expanded in the future to something more descriptive for
the "multiple" case, like a range of values. For now, the single
value suffices.
The information regarding the core attributes can take on two values:
1) The actual core-type or core-eff
2) KMP_HW_CORE_TYPE_UNKNOWN if the core type is unknown, and
UNKNOWN_CORE_EFF (-1) if the core eff is unknown.
This new information is stored in th_topology_attrs. An example
how to get the core type, one would read
th_topology_attrs.core_type.
Differential Revision: https://reviews.llvm.org/D139854
This patch fixes the wrong format string used in `__kmpc_error`, which could
cause segment fault at runtime.
Reviewed By: jlpeyton
Differential Revision: https://reviews.llvm.org/D141889
When building the library with icc and using it on macOS 12,
the library destruction process is skipped which has many OMPT tests
failing for macOS 12. This change registers the
__kmp_internal_end_library() call for atexit() which will be a
harmless, redundant call for macOS 11 and below and the only destructor
called for macOS 12+.
Differential Revision: https://reviews.llvm.org/D139857
The current only way to obtain pinned memory with libomptarget is to use a custom allocator llvm_omp_target_alloc_host.
This reflects well the CUDA implementation of libomptarget, but it does not correctly expose the AMDGPU runtime API,
where any system allocated page can be locked/unlocked through a call to hsa_amd_memory_lock/unlock.
This patch enables users to allocate memory through malloc (mmap, sbreak) and then pin the related memory pages
with a libomptarget special call. It is a base support in the amdgpu libomptarget plugin to enable users to prelock
their host memory pages so that the runtime doesn't need to lock them itself for asynchronous memory transfers.
Reviewed By: jdoerfert, ye-luo
Differential Revision: https://reviews.llvm.org/D139208
This patch fixes assertion failure in dynamic schedule with 8 byte induction
variable. It uses acquire load instead of relaxed to ensure that steal_lock
pointer is not NULL.
Differential Revision: https://reviews.llvm.org/D139373
When a team nested inside a teams construct is allocated, it is
allocated to a size specified by the teams thread_limit. In the case
where any mechanism that might not grant the full thread_limit is in
use, we may get a smaller team. This possibility was not reflected in
the code when using the th_teams_size.nth value stored on the master
thread for the team. This value was never updated even when t_nproc on
the team itself was different. I added a line to update it shortly
before the team is forked.
Added a simple teams test that uses KMP_DYNAMIC_MODE=random to mimic
allocating teams with sizes <= thread_limit. Eventually, this
will segfault without the fix in this commit.
Differential Revision: https://reviews.llvm.org/D139960
Support for taskwait nowait clause with placeholder for runtime changes.
Reviewed By: cchen, ABataev
Differential Revision: https://reviews.llvm.org/D131830
I accidentally left out the test for the pinned API introduced by D138933. Adding it back.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D140077
This patch better integrates the target nowait functions with the tasking runtime. It splits the nowait execution into two stages: a dispatch stage, which triggers all the necessary asynchronous device operations and stores a set of post-processing procedures that must be executed after said ops; and a synchronization stage, responsible for synchronizing the previous operations in a non-blocking manner and running the appropriate post-processing functions. Suppose during the synchronization stage the operations are not completed. In that case, the attached hidden helper task is re-enqueued to any hidden helper thread to be later synchronized, allowing other target nowait regions to be concurrently dispatched.
Reviewed By: jdoerfert, tianshilei1992
Differential Revision: https://reviews.llvm.org/D132005
This patch adds API support for the atk_pinned trait for omp_alloc.
It does not implement kmp_target_lock_mem and kmp_target_unlock_mem in libomptarget,
but prepares libomp for it. Patches to libomptarget to implement
lock/unlock coming after this one.
Reviewed by: jlpeyton, jdoerfert
Differential Revision: https://reviews.llvm.org/D138933
This new function was added in b72f1ec9fbb14cd7d2f5112d2c52ef5cdd1aa94a,
but wasn't exported from the DLL on Windows.
This fixes the parallel/omp_parallel_if.c OpenMP testcase on
Windows.
If testing for a warning option like -Wno-<foo> with GCC, GCC won't
print any diagnostic at all, leading to the options being accepted
incorrectly. However later, if compiling a file that actually prints
another warning, GCC will also print warnings about these -Wno-<foo>
options being unrecognized.
This avoids warning spam like this, for every OpenMP source file that
produces build warnings with GCC:
cc1plus: warning: unrecognized command line option ‘-Wno-int-to-void-pointer-cast’
cc1plus: warning: unrecognized command line option ‘-Wno-return-type-c-linkage’
cc1plus: warning: unrecognized command line option ‘-Wno-covered-switch-default’
cc1plus: warning: unrecognized command line option ‘-Wno-enum-constexpr-conversion’
This matches how such warning options are detected and added in
llvm/cmake/modules/HandleLLVMOptions.cmake, e.g. like this:
check_cxx_compiler_flag("-Wclass-memaccess" CXX_SUPPORTS_CLASS_MEMACCESS_FLAG)
append_if(CXX_SUPPORTS_CLASS_MEMACCESS_FLAG "-Wno-class-memaccess" CMAKE_CXX_FLAGS)
This also matches how LLDB warning options were restructured for
GCC compatibility in e546bbfda0ab91cf78c096d8c035851cc7c3b9f3.
Differential Revision: https://reviews.llvm.org/D139922
This fixes the following test cases:
* affinity/kmp-affinity.c
* affinity/kmp-hw-subset.c
* affinity/omp-places.c
Differential Revision: https://reviews.llvm.org/D139802
Code for serial parallel regions and teams construct have been moved
out of __kmp_fork_call and into separate functions. This is to reduce
the size of the __kmp_fork_call function, and aid in debugging.
Differential Revision: https://reviews.llvm.org/D139116
This patch adds a new runtime function `fork_call_if` and uses that
to lower parallel if statements when going through OpenMPIRBuilder.
This fixes an issue where the OpenMPIRBuilder passes all arguments to
fork_call as a struct but this struct is not filled corretly in the
non-if branch by handling the fork inside the runtime.
Differential Revision: https://reviews.llvm.org/D138495
This fixes passing an arbitrarily large number of arguments to
microtasks, fixing the misc_bugs/many-microtask-args.c testcase on
ARM.
Differential Revision: https://reviews.llvm.org/D138704
Summary:
Building with `lld` now errors on undefined symbols by default now. This
was causing `libomp` to think that the compiler didn't support version
scripts when checking linker features. This patch adds a new script that
exports all symbols to be used for testing. We also remove the old
workarounds for undefined versions now that it's no longer necessary.
Define the same kmpc_atomic functions for arm and arm64 that are defined for x86 and x64.
Reviewed By: mstorsjo
Differential Revision: https://reviews.llvm.org/D139139
This patch fixes issues seen once https://reviews.llvm.org/D135402 is applied.
The exports_so.txt file attempts to export functions which may not exist
depending on which features are enabled/disabled in the OpenMP
runtime library. There are not many of these so exporting dummy
symbols is feasible.
* Export dummy __kmp_reset_stats() function when stats is disabled.
* Export dummy debugging data when USE_DEBUGGER is disabled
* Export dummy __kmp_itt_[fini|init]_ittlib() functions
when ITT Notify is disabled
* Export dummy __kmp_reap_monitor() function when KMP_USE_MONITOR
is disabled
* Remove __kmp_launch_monitor and __kmp_launch_worker from being exported.
They have been static symbols since library inception.
Fixes: https://github.com/llvm/llvm-project/issues/58858
Differential Revision: https://reviews.llvm.org/D138049
On ARM, a C fallback version of __kmp_invoke_microtask is used,
which only handles up to a fixed number of arguments - while
many-microtask-args.c tests that the function can handle an
arbitrarily large number of arguments (the testcase produces 17
arguments).
On the CMake level, we can't add ${LIBOMP_ARCH} directly to
OPENMP_TEST_COMPILER_FEATURES in OpenMPTesting.cmake, since
that file is parsed before LIBOMP_ARCH is set. Instead
convert the feature list into a proper CMake list, and append
${LIBOMP_ARCH} into it before serializing it to an Python array.
Reapply: Make sure OPENMP_TEST_COMPILER_FEATURES is defined
properly in all other test subdirectories other than
runtime/test too.
Differential Revision: https://reviews.llvm.org/D138738
This reverts commit 03bf001b6d95f7c6a88a2b95f3cad752b9d1ed45.
This commit broke a number of OpenMP buildbots, e.g.
https://lab.llvm.org/buildbot#builders/84/builds/31839, where
the build ends up with errors like this:
[0/1] Running OpenMP tests
llvm-lit: /b/1/openmp-clang-x86_64-linux-debian/llvm.src/llvm/utils/lit/lit/TestingConfig.py:140: fatal: unable to parse config file '/b/1/openmp-clang-x86_64-linux-debian/llvm.build/projects/openmp/libomptarget/test/x86_64-pc-linux-gnu/lit.site.cfg', traceback: Traceback (most recent call last):
File "/b/1/openmp-clang-x86_64-linux-debian/llvm.src/llvm/utils/lit/lit/TestingConfig.py", line 129, in load_from_path
exec(compile(data, path, 'exec'), cfg_globals, None)
File "/b/1/openmp-clang-x86_64-linux-debian/llvm.build/projects/openmp/libomptarget/test/x86_64-pc-linux-gnu/lit.site.cfg", line 6
config.test_compiler_features =
^
SyntaxError: invalid syntax
Use the correct data type for pointer sized integers on Windows;
"long" is always 32 bit, even on 64 bit Windows - don't use it
for the kmp_intptr_t type.
Provide the exact correct definition of the kmp_depend_info
struct - avoid the risk of mismatches (if a platform would pack
things slightly differently when things are declared differently).
Zero initialize the whole dep_info struct before filling it in;
if only setting the in/out bits, the rest of the unallocated bits
in the bitfield can have undefined values. Libomp reads the flags
in combined form as an kmp_uint8 by reading the flag field - thus,
the unused bits do need to be zeroed. (Alternatively, the flag field
could be set to zero before setting the individual bits in the
bitfield).
Use kmp_intptr_t instead of long for casting pointers to integers.
Differential Revision: https://reviews.llvm.org/D137748
On ARM, a C fallback version of __kmp_invoke_microtask is used,
which only handles up to a fixed number of arguments - while
many-microtask-args.c tests that the function can handle an
arbitrarily large number of arguments (the testcase produces 17
arguments).
On the CMake level, we can't add ${LIBOMP_ARCH} directly to
OPENMP_TEST_COMPILER_FEATURES in OpenMPTesting.cmake, since
that file is parsed before LIBOMP_ARCH is set. Instead
convert the feature list into a proper CMake list, and append
${LIBOMP_ARCH} into it before serializing it to an Python array.
Differential Revision: https://reviews.llvm.org/D138738
Windows heuristics may decide to want to run some tested processes
as elevated (since it may think some of them are installers - executables
with "dispatch" in the name may hit a heuristic looking for "patch").
Set this environment variable to disable this heuristic and just run
the executable with whatever privileges the caller has.
This fixes a couple tests on such versions of Windows where this
heuristic is active.
Differential Revision: https://reviews.llvm.org/D137772
This fixes compilation in the Clang-cl configuration on aarch64;
Clang doesn't implement all the aarch64 MSVC atomic intrinsics yet.
Differential Revision: https://reviews.llvm.org/D138737
This does things in the same way as
D137168 / a356782426f5bf54a00570e1f925345e5fda7b2e and
D101173 / 4fb0aaf03381473ec8af727edb4b5d59b64b0d60 did for aarch64.
This adds a C implementation of __kmp_invoke_microtask in the same
way as the fallback C implementation in z_Linux_util.cpp.
Both the existing C fallback used on arm linux, and this one added here,
fail test/misc_bugs/many-microtask-args.c similarly (which could be
considered as an XFAIL).
Differential Revision: https://reviews.llvm.org/D138689
fb947c358661b3bd3d5e1fa776ec74cc0f308854 introduced the gas
macro COMMON, but it was only defined within ifdefs of the form:
#if (KMP_OS_LINUX || KMP_OS_DARWIN || KMP_OS_WINDOWS) && KMP_ARCH_AARCH64
It was used, however, within other conditions:
#if KMP_ARCH_ARM || KMP_ARCH_MIPS
and:
#if KMP_ARCH_PPC64 || KMP_ARCH_AARCH64 || KMP_ARCH_MIPS64 || KMP_ARCH_RISCV64 || KMP_ARCH_LOONGARCH64
Move the definition of the COMMON macro out from the current ifdef,
so that it always gets defined (as it's only dependent on the target
platform).
This fixes building on ARM (and presumably all the other mentioned
architectures except aarch64).
Differential Revision: https://reviews.llvm.org/D138703
When building for Windows aarch64, and not using the actual MSVC,
we can assemble gnu assembly files just fine, and the existing
correct implementation of __kmp_invoke_microtask is fully usable.
The C implementation of __kmp_invoke_microtask in
z_Windows_NT-586_util.cpp relies on unguaranteed assumptions about
the compiler behaviour - it does work currently on MSVC, but doesn't
necessarily on other compilers. That function uses an alloca to pass
parameters on the stack to the called functions.
There's no guarantee that the buffer allocated by alloca is exactly
at the bottom of the stack when doing the call; the compiler might
have left space for extra things to save on the stack there.
Additionally, when compiled with Clang with optimization, Clang
optimizes out the alloca and memcpy entirely. On the C language
level, they don't have any visible effect outside of the function
and thus can be omitted entirely.
This fixes calling microtasks with more than 6 parameters, in
builds for Windows/aarch64 with Clang.
Differential Revision: https://reviews.llvm.org/D137827
This option is legacy and is removed from GNU ld's doc (many binutils
distributions are configured with --enable-textrel-check=). lld ignores the
option.
This fixes warnings like this:
```
openmp/runtime/test/omp_testsuite.h:107:60: warning: format specifies type 'unsigned int' but the argument has type 'DWORD' (aka 'unsigned long') [-Wformat]
fprintf(stderr, "CreateThread() failed: Error #%u.\n", GetLastError());
~~ ^~~~~~~~~~~~~~
%lu
```
Differential Revision: https://reviews.llvm.org/D137747
