summaryrefslogtreecommitdiff
path: root/openmp
AgeCommit message (Collapse)Author
2025-11-21[OpenMP][libomp] Add transparent task flag bit to kmp_tasking_flags (#168873)Zahira Ammarguellat
Clang is adding support for the new `OpenMP transparent` clause on `task` and `taskloop` directives. The parsing and semantic handling for this clause is introduced in https://github.com/llvm/llvm-project/pull/166810 . To allow the compiler to communicate this clause to the `OpenMP` runtime, a dedicated bit in `kmp_tasking_flags` is required. This patch adds a new compiler-reserved bit `transparent` to the` kmp_tasking_flags` structure.
2025-11-20[OpenMP][AIX] Not to create symbolic links to libomp.so in install step ↵Kelvin Li
(NFC) (#168585) Commit bb563b1 handles the links in the build directory but misses the case in the install step. This patch is to link only the libomp.a on AIX.
2025-11-19[Runtimes] Default build must use its own output dirs (#168266)Michael Kruse
Post-commit fix of #164794 reported at https://github.com/llvm/llvm-project/pull/164794#issuecomment-3536253493 `LLVM_LIBRARY_OUTPUT_INTDIR` and `LLVM_RUNTIME_OUTPUT_INTDIR` is used by `AddLLVM.cmake` as output directories. Unless we are in a bootstrapping-build, It must not point to directories found by `find_package(LLVM)` which may be read-only directories. MLIR for instance sets thesese variables to its own build output directory, so should the runtimes.
2025-11-18Revert "[OpenMP] Implement omp_get_uid_from_device() / ↵Robert Imschweiler
omp_get_device_from_uid()" (#168547) Reverts llvm/llvm-project#164392 due to fortran issues
2025-11-18[OpenMP] Implement omp_get_uid_from_device() / omp_get_device_from_uid() ↵Robert Imschweiler
(#164392) Use the implementation in libomptarget. If libomptarget is not available, always return the UID / device number of the host / the initial device.
2025-11-17[OpenMP][omptest] Fix missing source extentionMichael Kruse
The file extention was accidentally omitted from #164794.
2025-11-06[Offload] Remove handling for device memory pool (#163629)Joseph Huber
Summary: This was a lot of code that was only used for upstream LLVM builds of AMDGPU offloading. We have a generic and fast `malloc` in `libc` now so just use that. Simplifies code, can be added back if we start providing alternate forms but I don't think there's a single use-case that would justify it yet.
2025-11-03[OpenMP][AIX] Not to create symbolic links to libomp.so on AIX (#165890)Kelvin Li
On AIX, it generates libomp for both static and dynamic. There is no need to create symbolic links to libomp.so. --------- Co-authored-by: Xing Xue <xingxue@outlook.com>
2025-11-03[OpenMP][AArch64] Fix frame pointer save in microtask (#165313)Dominik Wójt (Cognizant)
When OMPT is enabled, the stack pointer was not saved to frame pointer register immediately after storing the frame pointer to the stack. Therefore the frame pointers did not constitute a proper chain. Fixes [#163352](https://github.com/llvm/llvm-project/issues/163352)
2025-10-31[OpenMP] Remove OS checks for ARM and AArch64 (#165640)Brad Smith
2025-10-27[openmp][cmake] Don't glob for build dependencies (#165231)Michael Kruse
LLVM's cmake standard explicitly lists all source in the CMakeLists.txt. Remove globbing for source files in OpenMP's CMakeLists.txt. Also see #4899, #71404, https://reviews.llvm.org/D79906, https://reviews.llvm.org/D31363, https://reviews.llvm.org/D61275, https://discourse.llvm.org/t/cmake-builds-clang/11536, and CMake's note at https://cmake.org/cmake/help/latest/command/file.html#glob. Two reasons to not glob for source files is that it breaks bisecting and incremental builds. Renaming a file, reverting or checking out an older reversion where a newly added source file disappears again will not trigger a CMake configure step and make the build fail because of a non-existing source file.
2025-10-21[NFCI][asm][i386/x86-64] Enable AT&T syntax explicitly (#164453)Raul Tambre
Implementation files using the Intel syntax explicitly specify it. Do the same for the few files using AT&T syntax. This also enables building LLVM with `-mllvm -x86-asm-syntax=intel` in one's Clang config files (i.e. a global preference for Intel syntax). No functional change intended.
2025-10-20[OpenMP][AArch64] Enable BTI and PAC support on OpenBSD (#164337)Brad Smith
2025-10-15[OpenMP][omptest] Add Dispatch equality operator (#162667)Michael Halkenhäuser
Add equality op which checks 'Kind' - For now this seems more reasonable than defaulting to true Chose to keep toString and equality unit tests separate
2025-10-15[OpenMP] Fix preprocessor mismatches between include and usages of hwloc ↵Peter Arzt
(#158349) Fix https://github.com/llvm/llvm-project/issues/156679 There is a mismatch between the preprocessor guards around the include of `hwloc.h` and those protecting its usages, leading to build failures on Darwin: https://github.com/spack/spack-packages/pull/1212 This change introduces `KMP_HWLOC_ENABLED` that reflects whether hwloc is actually used.
2025-10-12Fix typo: IsGlobaLinkage -> IsGlobalLinkage in XCOFF (#161960)小钟
Corrects the spelling of 'IsGlobaLinkage' to 'IsGlobalLinkage' in XCOFF-related code, comments, and tests across the codebase.
2025-10-08[OpenMP] Add IBM Z as supported architecture in the runtime READMEUlrich Weigand
This architecture has been supported since 1111ef025762d9b7ecc3cafc576083987ae63fe6, but the README file had not been updated.
2025-10-06[OpenMP][omptest] Enable missing callback (#161650)Jan Patrick Lehr
The registration of this callback handler was disabled for some reason. Local testing did not bring up any issues when I enabled it. Side effect is: Silences current warning about unused function.
2025-10-06[OpenMP] Clean-up Fortran testsMichael Kruse
* Use "do" for DO loops, there is no "for" in Fortran and it is always integer * Add -cpp to not rely on file name case * Add "implicit none" safety
2025-10-04[OpenMP][test] .f90 -> .F90Michael Kruse
The test makes use of the preprocessor, which requires a .F90 suffix
2025-10-03[Flang] Add standalone tile support (#160298)Michael Kruse
Add support for the standalone OpenMP tile construct: ```f90 !$omp tile sizes(...) DO i = 1, 100 ... ``` This is complementary to #143715 which added support for the tile construct as part of another loop-associated construct such as worksharing-loop, distribute, etc.
2025-09-29[OpenMP] Fix 'libc' configuration when building OpenMPJoseph Huber
Summary: Forgot to port this option's old handling from offload. It's not way easier since they're built in the same CMake project. Also delete the leftover directory that's not used anymore, don't know how that was still there.
2025-09-29[Clang][OpenMP][LoopTransformations] Implement "#pragma omp fuse" loop ↵Walter J.T.V
transformation directive and "looprange" clause (#139293) This change implements the fuse directive, `#pragma omp fuse`, as specified in the OpenMP 6.0, along with the `looprange` clause in clang. This change also adds minimal stubs so flang keeps compiling (a full implementation in flang of this directive is still pending). --------- Co-authored-by: Roger Ferrer Ibanez <roger.ferrer@bsc.es>
2025-09-26[Flang][OpenMP] Enable no-loop kernels (#155818)Dominik Adamski
Enable the generation of no-loop kernels for Fortran OpenMP code. target teams distribute parallel do pragmas can be promoted to no-loop kernels if the user adds the -fopenmp-assume-teams-oversubscription and -fopenmp-assume-threads-oversubscription flags. If the OpenMP kernel contains reduction or num_teams clauses, it is not promoted to no-loop mode. The global OpenMP device RTL oversubscription flags no longer force no-loop code generation for Fortran.
2025-09-20[openmp][test] Don't use random Flang by defaultMichael Kruse
Only enable Fortran tests when either the test compiler is set explicitly, or in a runtimes bootstrapping build. A system-installed Flang either may not exist, or too old to compiler our tests. Fixes buildbot failure after landing #150722 https://lab.llvm.org/buildbot/#/builders/10/builds/13905
2025-09-20[OpenMP] Allow Fortran tests (#150722)Michael Kruse
In addition to existing C/C++ tests, add Fortran-based tests. Fortran tests will only run if a Fortran compiler is found. The first test is for the unroll construct added in #144785.
2025-09-19[OpenMP][NFC] Clean up a bunch of warnings and clang-tidy messages (#159831)Joseph Huber
Summary: I made the GPU flags accept more of the default LLVM warnings, which triggered some new cases. Clean those up and fix some other ones while I'm at it.
2025-09-19[LLVM] Simplify GPU runtimes flag handling (#159802)Joseph Huber
Summary: The AMDGPU hack can be removed, and we no longer need to skip 90% of the `HandleLLVMOptions` if we work around NVPTX earlier. Simplifies the interface by removing duplicated logic and keeps the GPU targets from being weirdly divergent on some flags.
2025-09-16[OpenMP] Document how to specify flags to device libraries (#159053)Tulio Magno Quites Machado Filho
Add an explanation on how to use RUNTIMES_<triple>_CMAKE_CXX_FLAGS in order to specify different compiler flags for OpenMP device libraries.
2025-09-15[OpenMP] [Tests] Update test broken by #157364 (#158751)Sirraide
Fix another test impacted by #157364. On Windows, `GetComputerNameA()`, which is what this ends up calling, takes an `LPDWORD`, but we were handing it an `int*`; fix this by declaring it as a `DWORD` instead.
2025-09-11[offload][OpenMP] Remove device code for num_threads strict (#157893)Robert Imschweiler
Due to potential performance issues, this commit temporarily removes support for the num_threads 'strict' modifier and its corresponding message and severity clauses on the device.
2025-09-08[OpenMP] Fix incorrect CUDA bc path after library change (#157547)Joseph Huber
2025-09-08[OpenMP] Change build of OpenMP device runtime to be a separate runtime ↵Joseph Huber
(#136729) Summary: Currently we build the OpenMP device runtime as part of the `offload/` project. This is problematic because it has several restrictions when compared to the normal offloading runtime. It can only be built with an up-to-date clang and we need to set the target appropriately. Currently we hack around this by creating the compiler invocation manually, but this patch moves it into a separate runtimes build. This follows the same build we use for libc, libc++, compiler-rt, and flang-rt. This also moves it from `offload/` into `openmp/` because it is still the `openmp/` runtime and I feel it is more appropriate. We do want a generic `offload/` library at some point, but it would be trivial to then add that as a separate library now that we have the infrastructure that makes adding these new libraries trivial. This most importantly will require that users update their build configs, mostly adding the following lines at a minimum. I was debating whether or not I should 'auto-upgrade' this, but I just went with a warning. ``` -DLLVM_RUNTIME_TARGETS='default;amdgcn-amd-amdhsa;nvptx64-nvidia-cuda' \ -DRUNTIMES_nvptx64-nvidia-cuda_LLVM_ENABLE_RUNTIMES=openmp \ -DRUNTIMES_amdgcn-amd-amdhsa_LLVM_ENABLE_RUNTIMES=openmp \ ``` This also changed where the `.bc` version of the library lives, but it's still created.
2025-08-31[openmp] Fix missing include directory in omptest tool (#156194)Michał Górny
Add missing `LIBOMP_INCLUDE_DIR` include directory to fix build failures in omptest, as reported in https://github.com/llvm/llvm-project/pull/154786#issuecomment-3223481804. Thanks fo @jprotze for the suggested fix. Signed-off-by: Michał Górny <mgorny@gentoo.org>
2025-08-30[OpenMP] Use Clang resource dir only in bootstrapping build (#156018)Michael Kruse
In an LLVM_ENABLE_PROJECTS=openmp build, the LLVM build tree in which just-built Clang is available, but in contrast to an LLVM_ENABLE_RUNTIMES=openmp build, is not the compiler that openmp is built with (CMAKE_CXX_COMPILER). The latter compiler (which might also be gcc) will not look into the resource directory of just-built Clang, where the OpenMP headers are installed. There may not even be a just-built Clang without LLVM_ENABLE_PROJECTS=clang. We cannot add the OpenMP header output directory to the search path which also include's Clang's internal headers that will conflict with CMAKE_CXX_COMPILER's internal headers. The only choice left is to use what the OpenMP standalone build does: Use CMAKE_CURRENT_BINARY_DIR which is added unconditionally to the header search path to compile openmp itself.
2025-08-28Revert "[OpenMP][clang] 6.0: num_threads strict (part 3: codegen)" (#155809)Robert Imschweiler
Reverts llvm/llvm-project#146405
2025-08-28[OpenMP][clang] 6.0: num_threads strict (part 3: codegen) (#146405)Robert Imschweiler
OpenMP 6.0 12.1.2 specifies the behavior of the strict modifier for the num_threads clause on parallel directives, along with the message and severity clauses. This commit implements necessary codegen changes.
2025-08-27[OpenMP][ompTest] Guard installation of all components (#155433)Michael Halkenhäuser
Make installation of ompTest optional via: -DLIBOMPTEST_INSTALL_COMPONENTS=ON (default: OFF)
2025-08-27[Flang-RT][OpenMP] Define _GLIBCXX_NO_ASSERTIONS (#155440)Michael Kruse
Since GCC 15.1, libstdc++ enabled assertions/hardening by default in non-optimized (-O0) builds [1]. That is, _GLIBCXX_ASSERTIONS is defined in the libstdc++ headers itself so defining/undefining it on the compiler command line no longer has an effect in non-optimized builds. As the commit message[2] suggests, define _GLIBCXX_NO_ASSERTIONS instead. For libstdc++ headers before 15.1, -U_GLIBCXX_ASSERTIONS still has to be on the command line as well. Defining _GLIBCXX_NO_ASSERTIONS was previously proposed in #152223 [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112808 [2] https://github.com/gcc-mirror/gcc/commit/361d230fd7800a7e749aba8ed020f54f5c26d504
2025-08-22[OpenMP][omptest] Skip omptest build if LLVM_INCLUDE_TESTS=OFF (#155020)Michael Halkenhäuser
Add / expand early exit in CMakeLists.txt if LLVM_INCLUDE_TESTS is 'OFF'
2025-08-22[OpenMP][omptest] Enforce test case order for 'standalone' build (#154977)Michael Halkenhäuser
Note: this only applies to 'standalone' builds, i.e. when: LIBOMPTEST_BUILD_STANDALONE evaluates to 'ON'. Use std::vector<std::pair<std::string, TestSuite>> instead of a std::map. Background: In some cases it could happen that the test execution order would change vs. the order of appearance. This can lead to suite failures when e.g. testing for device initialization because it is performed by the first executed test case. By storing the test suites and cases in order of appearance this issue is avoided. (So far GoogleTest has behaved in the same way.)
2025-08-22Reland: [OpenMP] Add ompTest library to OpenMP (#154786)Michael Halkenhäuser
Reland of https://github.com/llvm/llvm-project/pull/147381 Added changes to fix observed BuildBot failures: * CMake version (reduced minimum to `3.20`, was: `3.22`) * GoogleTest linking (missing `./build/lib/libllvm_gtest.a`) * Related header issue (missing `#include "llvm/Support/raw_os_ostream.h"`) Original message Description =========== OpenMP Tooling Interface Testing Library (ompTest) ompTest is a unit testing framework for testing OpenMP implementations. It offers a simple-to-use framework that allows a tester to check for OMPT events in addition to regular unit testing code, supported by linking against GoogleTest by default. It also facilitates writing concise tests while bridging the semantic gap between the unit under test and the OMPT-event testing. Background ========== This library has been developed to provide the means of testing OMPT implementations with reasonable effort. Especially, asynchronous or unordered events are supported and can be verified with ease, which may prove to be challenging with LIT-based tests. Additionally, since the assertions are part of the code being tested, ompTest can reference all corresponding variables during assertion. Basic Usage =========== OMPT event assertions are placed before the code, which shall be tested. These assertion can either be provided as one block or interleaved with the test code. There are two types of asserters: (1) sequenced "order-sensitive" and (2) set "unordered" assserters. Once the test is being run, the corresponding events are triggered by the OpenMP runtime and can be observed. Each of these observed events notifies asserters, which then determine if the test should pass or fail. Example (partial, interleaved) ============================== ```c++ int N = 100000; int a[N]; int b[N]; OMPT_ASSERT_SEQUENCE(Target, TARGET, BEGIN, 0); OMPT_ASSERT_SEQUENCE(TargetDataOp, ALLOC, N * sizeof(int)); // a ? OMPT_ASSERT_SEQUENCE(TargetDataOp, H2D, N * sizeof(int), &a); OMPT_ASSERT_SEQUENCE(TargetDataOp, ALLOC, N * sizeof(int)); // b ? OMPT_ASSERT_SEQUENCE(TargetDataOp, H2D, N * sizeof(int), &b); OMPT_ASSERT_SEQUENCE(TargetSubmit, 1); OMPT_ASSERT_SEQUENCE(TargetDataOp, D2H, N * sizeof(int), nullptr, &b); OMPT_ASSERT_SEQUENCE(TargetDataOp, D2H, N * sizeof(int), nullptr, &a); OMPT_ASSERT_SEQUENCE(TargetDataOp, DELETE); OMPT_ASSERT_SEQUENCE(TargetDataOp, DELETE); OMPT_ASSERT_SEQUENCE(Target, TARGET, END, 0); #pragma omp target parallel for { for (int j = 0; j < N; j++) a[j] = b[j]; } ``` References ========== This work has been presented at SC'24 workshops, see: https://ieeexplore.ieee.org/document/10820689 Current State and Future Work ============================= ompTest's development was mostly device-centric and aimed at OMPT device callbacks and device-side tracing. Consequentially, a substantial part of host-related events or features may not be supported in its current state. However, we are confident that the related functionality can be added and ompTest provides a general foundation for future OpenMP and especially OMPT testing. This PR will allow us to upstream the corresponding features, like OMPT device-side tracing in the future with significantly reduced risk of introducing regressions in the process. Build ===== ompTest is linked against LLVM's GoogleTest by default, but can also be built 'standalone'. Additionally, it comes with a set of unit tests, which in turn require GoogleTest (overriding a standalone build). The unit tests are added to the `check-openmp` target. Use the following parameters to perform the corresponding build: `LIBOMPTEST_BUILD_STANDALONE` (Default: ${OPENMP_STANDALONE_BUILD}) `LIBOMPTEST_BUILD_UNITTESTS` (Default: OFF) --------- Co-authored-by: Jan-Patrick Lehr <JanPatrick.Lehr@amd.com> Co-authored-by: Joachim <protze@rz.rwth-aachen.de> Co-authored-by: Joachim Jenke <jenke@itc.rwth-aachen.de>
2025-08-21Revert "Fix Debug Build Using GCC 15" (#154877)dpalermo
Reverts llvm/llvm-project#152223
2025-08-21Fix Debug Build Using GCC 15 (#152223)Patrick Simmons
Flang currently doesn't build in debug mode on GCC 15 due to missing dynamic libraries in some CMakeLists.txt files, and OpenMP doesn't link in debug mode due to the atomic library pulling in libstdc++ despite an incomplete attempt in the CMakeLists.txt to disable glibcxx assertions. This PR fixes these issues and allows Flang and the OpenMP runtime to build and link on GCC 15 in debug mode. --------- Co-authored-by: ronlieb <ron.lieberman@amd.com>
2025-08-21Revert "[OpenMP] Add ompTest library to OpenMP" (#154742)Jan Patrick Lehr
Reverts llvm/llvm-project#147381 A few buildbot failures for different reasons.
2025-08-21[OpenMP] Add ompTest library to OpenMP (#147381)Michael Halkenhäuser
Description =========== OpenMP Tooling Interface Testing Library (ompTest) ompTest is a unit testing framework for testing OpenMP implementations. It offers a simple-to-use framework that allows a tester to check for OMPT events in addition to regular unit testing code, supported by linking against GoogleTest by default. It also facilitates writing concise tests while bridging the semantic gap between the unit under test and the OMPT-event testing. Background ========== This library has been developed to provide the means of testing OMPT implementations with reasonable effort. Especially, asynchronous or unordered events are supported and can be verified with ease, which may prove to be challenging with LIT-based tests. Additionally, since the assertions are part of the code being tested, ompTest can reference all corresponding variables during assertion. Basic Usage =========== OMPT event assertions are placed before the code, which shall be tested. These assertion can either be provided as one block or interleaved with the test code. There are two types of asserters: (1) sequenced "order-sensitive" and (2) set "unordered" assserters. Once the test is being run, the corresponding events are triggered by the OpenMP runtime and can be observed. Each of these observed events notifies asserters, which then determine if the test should pass or fail. Example (partial, interleaved) ============================== ```c++ int N = 100000; int a[N]; int b[N]; OMPT_ASSERT_SEQUENCE(Target, TARGET, BEGIN, 0); OMPT_ASSERT_SEQUENCE(TargetDataOp, ALLOC, N * sizeof(int)); // a ? OMPT_ASSERT_SEQUENCE(TargetDataOp, H2D, N * sizeof(int), &a); OMPT_ASSERT_SEQUENCE(TargetDataOp, ALLOC, N * sizeof(int)); // b ? OMPT_ASSERT_SEQUENCE(TargetDataOp, H2D, N * sizeof(int), &b); OMPT_ASSERT_SEQUENCE(TargetSubmit, 1); OMPT_ASSERT_SEQUENCE(TargetDataOp, D2H, N * sizeof(int), nullptr, &b); OMPT_ASSERT_SEQUENCE(TargetDataOp, D2H, N * sizeof(int), nullptr, &a); OMPT_ASSERT_SEQUENCE(TargetDataOp, DELETE); OMPT_ASSERT_SEQUENCE(TargetDataOp, DELETE); OMPT_ASSERT_SEQUENCE(Target, TARGET, END, 0); #pragma omp target parallel for { for (int j = 0; j < N; j++) a[j] = b[j]; } ``` References ========== This work has been presented at SC'24 workshops, see: https://ieeexplore.ieee.org/document/10820689 Current State and Future Work ============================= ompTest's development was mostly device-centric and aimed at OMPT device callbacks and device-side tracing. Consequentially, a substantial part of host-related events or features may not be supported in its current state. However, we are confident that the related functionality can be added and ompTest provides a general foundation for future OpenMP and especially OMPT testing. This PR will allow us to upstream the corresponding features, like OMPT device-side tracing in the future with significantly reduced risk of introducing regressions in the process. Build ===== ompTest is linked against LLVM's GoogleTest by default, but can also be built 'standalone'. Additionally, it comes with a set of unit tests, which in turn require GoogleTest (overriding a standalone build). The unit tests are added to the `check-openmp` target. Use the following parameters to perform the corresponding build: `LIBOMPTEST_BUILD_STANDALONE` (Default: ${OPENMP_STANDALONE_BUILD}) `LIBOMPTEST_BUILD_UNITTESTS` (Default: OFF) --------- Co-authored-by: Jan-Patrick Lehr <JanPatrick.Lehr@amd.com> Co-authored-by: Joachim <protze@rz.rwth-aachen.de>
2025-08-20[NFC][CMake] quote ${CMAKE_SYSTEM_NAME} consistently (#154537)David Tenty
A CMake change included in CMake 4.0 makes `AIX` into a variable (similar to `APPLE`, etc.) https://gitlab.kitware.com/cmake/cmake/-/commit/ff03db6657c38c8cf992877ea66174c33d0bcb0b However, `${CMAKE_SYSTEM_NAME}` unfortunately also expands exactly to `AIX` and `if` auto-expands variable names in CMake. That means you get a double expansion if you write: `if (${CMAKE_SYSTEM_NAME} MATCHES "AIX")` which becomes: `if (AIX MATCHES "AIX")` which is as if you wrote: `if (ON MATCHES "AIX")` You can prevent this by quoting the expansion of "${CMAKE_SYSTEM_NAME}", due to policy [CMP0054](https://cmake.org/cmake/help/latest/policy/CMP0054.html#policy:CMP0054) which is on by default in 4.0+. Most of the LLVM CMake already does this, but this PR fixes the remaining cases where we do not.
2025-08-20[OpenMP][OMPD] Fix GDB plugin to work correctly when installed (#153956)Michał Górny
Fix the `sys.path` logic in the GDB plugin to insert the intended self-path in the first position rather than appending it to the end. The latter implied that if `sys.path` (naturally) contained the GDB's `gdb-plugin` directory, `import ompd` would return the top-level `ompd/__init__.py` module rather than the `ompd/ompd.py` submodule, as intended by adding the `ompd/` directory to `sys.path`. This is intended to be a minimal change necessary to fix the issue. Alternatively, the code could be modified to import `ompd.ompd` and stop modifying `sys.path` entirely. However, I do not know why this option was chosen in the first place, so I can't tell if this won't break something. Fixes #153954 Signed-off-by: Michał Górny <mgorny@gentoo.org>
2025-08-18[OpenMP][Test][NFC] output tool data as hex to improve readibility (#152757)Joachim
Using hex format allows to better interpret IDs: the first digits represent the thread number, the last digits represent the ID within a thread The main change is in callback.h: PRIu64 -> PRIx64 The patch also guards RUN/CHECK lines in openmp/runtime/tests/ompt with clang-format on/off comments and clang-formats the directory. --------- Co-authored-by: Kaloyan Ignatov <kaloyan.ignatov@rwth-aachen.de>
2025-08-15[OpenMP] Update ompdModule.c printf to match argument type (#152785)CatherineMoore
Update printf format string to match argument list --------- Co-authored-by: Joachim <protze@rz.rwth-aachen.de> Co-authored-by: Joachim Jenke <jenke@itc.rwth-aachen.de>