summaryrefslogtreecommitdiff
path: root/openmp/libompd/src
AgeCommit message (Collapse)Author
2024-07-05[ompd] Fix strict aliasing violation in TargetValue::getValue() (#97739)Nikita Popov
For the case where baseTypeSize does not match the size of T, read the value into a separate char buffer first. This avoids accessing buf using two different types. Fixes https://github.com/llvm/llvm-project/issues/94616.
2024-02-27[OpenMP][OMPD] libompd must not link libomp (#83119)Joachim
Fixes a regression introduced in 91ccd8248. The code for libompd includes kmp.h for enum kmp_sched. The dependency to hwloc is not necessary. Avoid the dependency by skipping the definitions in kmp.h using types from hwloc.h. Fixes #80750
2023-05-27Reland "[CMake] Bumps minimum version to 3.20.0.Mark de Wever
This reverts commit d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6. Adds the patch by @hans from https://github.com/llvm/llvm-project/issues/62719 This patch fixes the Windows build. d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6 reverted the reviews D144509 [CMake] Bumps minimum version to 3.20.0. This partly undoes D137724. This change has been discussed on discourse https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193 Note this does not remove work-arounds for older CMake versions, that will be done in followup patches. D150532 [OpenMP] Compile assembly files as ASM, not C Since CMake 3.20, CMake explicitly passes "-x c" (or equivalent) when compiling a file which has been set as having the language C. This behaviour change only takes place if "cmake_minimum_required" is set to 3.20 or newer, or if the policy CMP0119 is set to new. Attempting to compile assembly files with "-x c" fails, however this is workarounded in many cases, as OpenMP overrides this with "-x assembler-with-cpp", however this is only added for non-Windows targets. Thus, after increasing cmake_minimum_required to 3.20, this breaks compiling the GNU assembly for Windows targets; the GNU assembly is used for ARM and AArch64 Windows targets when building with Clang. This patch unbreaks that. D150688 [cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump The build uses other mechanism to select the runtime. Fixes #62719 Reviewed By: #libc, Mordante Differential Revision: https://reviews.llvm.org/D151344
2023-05-17Revert "Reland "[CMake] Bumps minimum version to 3.20.0.""Nico Weber
This reverts commit 65429b9af6a2c99d340ab2dcddd41dab201f399c. Broke several projects, see https://reviews.llvm.org/D144509#4347562 onwards. Also reverts follow-up commit "[OpenMP] Compile assembly files as ASM, not C" This reverts commit 4072c8aee4c89c4457f4f30d01dc9bb4dfa52559. Also reverts fix attempt "[cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump" This reverts commit 7d47dac5f828efd1d378ba44a97559114f00fb64.
2023-05-13Reland "[CMake] Bumps minimum version to 3.20.0."Mark de Wever
The owner of the last two failing buildbots updated CMake. This reverts commit e8e8707b4aa6e4cc04c0cffb2de01d2de71165fc.
2023-05-06Revert "Reland "[CMake] Bumps minimum version to 3.20.0.""Mark de Wever
Unfortunatly not all buildbots are updated. This reverts commit ffb807ab5375b3f78df198dc5d4302b3b552242f.
2023-05-06Reland "[CMake] Bumps minimum version to 3.20.0."Mark de Wever
All build bots should be updated now. This reverts commit 44d38022ab29a3156349602733b3459df5beef93.
2023-04-15Revert "Revert "Revert "[CMake] Bumps minimum version to 3.20.0."""Mark de Wever
This reverts commit 1ef4c3c859728008cf707cad8d67f45ae5070ae1. Two buildbots still haven't been updated.
2023-04-15Revert "Revert "[CMake] Bumps minimum version to 3.20.0.""Mark de Wever
This reverts commit 92523a35a827539db8557bbc3ecab7f9ea3f6ade. Reland to see whether CIs are updated.
2023-03-18Revert "Reland "[CMake] Bumps minimum version to 3.20.0.""Mark de Wever
This reverts commit a72165e5df59032cdd54dcb18155f2630d73abd1. Some buildbots have not been updated yet.
2023-03-18Reland "[CMake] Bumps minimum version to 3.20.0."Mark de Wever
This reverts commit 92523a35a827539db8557bbc3ecab7f9ea3f6ade. Test whether all CI runners are updated.
2023-03-04Revert "[CMake] Bumps minimum version to 3.20.0."Mark de Wever
Some build bots have not been updated to the new minimal CMake version. Reverting for now and ping the buildbot owners. This reverts commit 44c6b905f8527635e49bb3ea97dea315f92d38ec.
2023-03-04[CMake] Bumps minimum version to 3.20.0.Mark de Wever
This partly undoes D137724. This change has been discussed on discourse https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193 Note this does not remove work-arounds for older CMake versions, that will be done in followup patches. Reviewed By: mehdi_amini, MaskRay, ChuanqiXu, to268, thieta, tschuett, phosek, #libunwind, #libc_vendors, #libc, #libc_abi, sivachandra, philnik, zibi Differential Revision: https://reviews.llvm.org/D144509
2022-04-22[Clang][OpenMP] libompd: get libomp hwloc includedir by target_link_librariesYe Luo
When hwloc is used and is installed outside of the default paths, the omp CMake target needs to provide the needed include path thru the CMake target by adding it with target_include_directories to it, so libompd gets it as well when it defines it's cmake target using target_link_libraries. As suggested in D122667 Reviewed By: ye-luo Differential Revision: https://reviews.llvm.org/D123888
2022-01-22[openmp][cmake] Use `GNUInstallDirs` to support custom installation dirsJohn Ericson
I am breaking apart D99484 so the cause of build failures is easier to understand. Differential Revision: https://reviews.llvm.org/D117945
2022-01-16Revert "[cmake] Use `GNUInstallDirs` to support custom installation dirs."John Ericson
https://lab.llvm.org/buildbot/#/builders/46/builds/21146 Still have this odd error, not sure how to reproduce, so I will just try breaking up my patch. This reverts commit 4a678f8072004eff9214c1a4e1836a14abb69535.
2022-01-16[cmake] Use `GNUInstallDirs` to support custom installation dirs.John Ericson
This is the original patch in my GNUInstallDirs series, now last to merge as the final piece! It arose as a new draft of D28234. I initially did the unorthodox thing of pushing to that when I wasn't the original author, but since I ended up - Using `GNUInstallDirs`, rather than mimicking it, as the original author was hesitant to do but others requested. - Converting all the packages, not just LLVM, effecting many more projects than LLVM itself. I figured it was time to make a new revision. I have used this patch series (and many back-ports) as the basis of https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS), which was merged last spring (2021). It looked like people were generally on board in D28234, but I make note of this here in case extra motivation is useful. --- As pointed out in the original issue, a central tension is that LLVM already has some partial support for these sorts of things. Variables like `COMPILER_RT_INSTALL_PATH` have already been dealt with. Variables like `LLVM_LIBDIR_SUFFIX` however, will require further work, so that we may use `CMAKE_INSTALL_LIBDIR`. These remaining items will be addressed in further patches. What is here is now rote and so we should get it out of the way before dealing more intricately with the remainder. Reviewed By: #libunwind, #libc, #libc_abi, compnerd Differential Revision: https://reviews.llvm.org/D99484
2022-01-15Revert "[cmake] Use `GNUInstallDirs` to support custom installation dirs."John Ericson
Sorry for the disruption, I will try again later. This reverts commit efeb50197091b2ade24c00b9d55814bc433a7fd1.
2022-01-15[cmake] Use `GNUInstallDirs` to support custom installation dirs.John Ericson
This is the original patch in my GNUInstallDirs series, now last to merge as the final piece! It arose as a new draft of D28234. I initially did the unorthodox thing of pushing to that when I wasn't the original author, but since I ended up - Using `GNUInstallDirs`, rather than mimicking it, as the original author was hesitant to do but others requested. - Converting all the packages, not just LLVM, effecting many more projects than LLVM itself. I figured it was time to make a new revision. I have used this patch series (and many back-ports) as the basis of https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS), which was merged last spring (2021). It looked like people were generally on board in D28234, but I make note of this here in case extra motivation is useful. --- As pointed out in the original issue, a central tension is that LLVM already has some partial support for these sorts of things. Variables like `COMPILER_RT_INSTALL_PATH` have already been dealt with. Variables like `LLVM_LIBDIR_SUFFIX` however, will require further work, so that we may use `CMAKE_INSTALL_LIBDIR`. These remaining items will be addressed in further patches. What is here is now rote and so we should get it out of the way before dealing more intricately with the remainder. Reviewed By: #libunwind, #libc, #libc_abi, compnerd Differential Revision: https://reviews.llvm.org/D99484
2021-10-27[OpenMP][OMPD] Implementation of OMPD debugging library - libompd.Vignesh Balasubramanian
This is a continuation of the review: https://reviews.llvm.org/D100183 It contains routines that retrieve OpenMP ICV values for OMPD. Reviewed By: @hbae Differential Revision: https://reviews.llvm.org/D100184
2021-09-27[OpenMP][OMPD] Implementation of OMPD debugging library - libompd.Vignesh Balu
This is a continuation of the review: https://reviews.llvm.org/D100182 This patch implements the OMPD API as specified in the standard doc. Reviewed By: @hbae Differential Revision: https://reviews.llvm.org/D100183
2021-09-13[OpenMP] [OMPD] OPENMP_INSTALL_LIBDIR is set for the install dirVignesh Balasubramanian
OPENMP_INSTALL_LIBDIR is set to the installation path of shared and static libompd.This should avoid the mixing of 32 and 64 bit on same path in multi-lib set-up. Reviewed By: @mceier Differential Revision: https://reviews.llvm.org/D109352
2021-09-01[OpenMP][OMPD] Implementation of OMPD debugging library - libompd.Vignesh Balasubramanian
This is a continuation of the review: https://reviews.llvm.org/D100181 Creates a new directory "libompd" under openmp. "TargetValue" provides operational access to the OpenMP runtime memory for OMPD APIs. With TargetValue, using "pointer" a user can do multiple operations from casting, dereferencing to accessing an element for structure. The member functions are designed to concatenate the operations that are needed to access values from structures. e.g., _a[6]->_b._c would read like : TValue(ctx, "_a").cast("A",2) .getArrayElement(6).access("_b").cast("B").access("_c") For example: If you have a pointer "ThreadHandle" of a running program then you can access/retrieve "threadID" from the memory using TargetValue as below. TValue(context, thread_handle->th) /*__kmp_threads[t]->th*/ .cast("kmp_base_info_t") .access("th_info") /*__kmp_threads[t]->th.th_info*/ .cast("kmp_desc_t") .access("ds") /*__kmp_threads[t]->th.th_info.ds*/ .cast("kmp_desc_base_t") .access("ds_thread") /*__kmp_threads[t]->th.th_info.ds.ds_thread*/ .cast("kmp_thread_t") .getRawValue(thread_id, 1); Reviewed By: @hbae Differential Revision: https://reviews.llvm.org/D100182