- User Since
- Jun 3 2014, 8:03 PM (421 w, 6 d)
Apr 6 2022
Not sure if it is related. If I do a clean make check-openmp, I see many failures due to missing FileCheck etc.
... $ "build-llvm/./bin/FileCheck" "/llvm-project/openmp/runtime/test/ompt/parallel/nested_threadnum.c" # command stderr: 'build-llvm/./bin/FileCheck': command not found error: command failed with exit status: 127
Feb 4 2022
@igor.kirillov I try it on x86_64 and the patch works.
@igor.kirillov Adding // UNSUPPORTED: aarch64 may not work because the config.target_triplet is empty. Actually, it currently does not work on Power with // UNSUPPORTED: powerpc. And I experiment the following changes but I am not sure about the overall impact.
It works on Power9. Thanks.
Feb 3 2022
Oct 26 2021
@AndreyChurbanov There is one more issue. kmp_atomic_float10_max_min.c specifies -mlong-double-80 but some platforms (e.g. Power) do not support such option.
Oct 21 2021
Is this patch only applicable to KMP_ARCH_X86 || KMP_ARCH_X86_64 arch? The newly added test cases fail on non-X86 platform due to undefined symbols. The __kmpc_atomic_*_cas_* prototypes got preprocessed out inside the extern "C" hence the names are mangled.
Jul 28 2021
@tlwilmar It builds successfully on Power9 running RHEL 8.2. Thanks.
Jul 15 2021
@tlwilmar Is kmp_barrier.h accidentally removed in the latest update?
Jul 13 2021
Thanks Terry. Unfortunately, I got the following errors.
CMakeFiles/omp.dir/kmp_runtime.cpp.o: In function `~kmp_flag_64': llvm-project/openmp/runtime/src/kmp.h:266: undefined reference to `operator delete(void*)' CMakeFiles/omp.dir/kmp_runtime.cpp.o: In function `~kmp_flag_native': llvm-project/openmp/runtime/src/kmp_wait_release.h:157: undefined reference to `operator delete(void*)' CMakeFiles/omp.dir/kmp_barrier.cpp.o: In function `~kmp_flag_oncore': llvm-project/openmp/runtime/src/kmp_wait_release.h:955: undefined reference to `operator delete(void*)' CMakeFiles/omp.dir/kmp_barrier.cpp.o: In function `~kmp_flag_native': llvm-project/openmp/runtime/src/kmp_wait_release.h:157: undefined reference to `operator delete(void*)' CMakeFiles/omp.dir/kmp_barrier.cpp.o: In function `~kmp_flag_64': /llvm-project/openmp/runtime/src/kmp_wait_release.h:855: undefined reference to `operator delete(void*)' CMakeFiles/omp.dir/kmp_barrier.cpp.o:llvm-project/openmp/runtime/src/kmp_wait_release.h:157: more undefined references to `operator delete(void*)' follow
Jul 12 2021
Is the diff from HEAD? I try to build it but the patch cannot be applied to the trunk.
Jun 23 2021
Does D104788 take care of it?
Jun 18 2021
Building on Power running RHEL has the following errors.
/llvm-project/openmp/runtime/src/kmp_barrier.cpp:371:3: error: use of undeclared identifier 'KMP_MFENCE' KMP_MFENCE(); ^
Apr 29 2021
The following regressions seem to be caused by this patch on Power9+V100.
Unexpectedly Passed Tests (4): libomptarget :: nvptx64-nvidia-cuda :: unified_shared_memory/api.c libomptarget :: nvptx64-nvidia-cuda :: unified_shared_memory/close_enter_exit.c libomptarget :: nvptx64-nvidia-cuda :: unified_shared_memory/close_modifier.c libomptarget :: nvptx64-nvidia-cuda :: unified_shared_memory/shared_update.c
Apr 13 2021
No more comments from the community. I think it is okay to accept this revision. Thanks.
Mar 18 2021
I tried the patch in our environment and it works. LG. Thanks.
Jan 25 2021
I am seeing these errors.
Jan 22 2021
Jan 18 2021
Jan 5 2021
It looks fine. Thanks.
Jan 4 2021
Aug 25 2020
default(firstprivate) was added in https://reviews.llvm.org/rG78443666bc18a6957d279a0f58319c8a3e57771a
present map type and motion modifier
Jun 30 2020
Mar 14 2020
Feb 25 2020
Somewhat related, that means Clang issues a warning for every compilation should there be a "unsupported" CUDA version around, even if it's not used? @tra maybe we can only issue the warning if CUDA is going to be used?
Feb 21 2020
Since it is a TR8 feature, should we have this guarded by -fopenmp-version=?
So an alternative is to:
- patch openmp/runtime/cmake/LibompCheckLinkerFlag.cmake to make the libomp_check_linker_flag function to ignore the "Unknown CUDA version" warning, AND
- ask users to build with -DCMAKE_CXX_FLAGS=-Wno-unknown-cuda-version -DCMAKE_C_FLAGS=-Wno-unknown-cuda-version to get around the C_SUPPORTS_FPIC test in cmake/modules/HandleLLVMOptions.cmake if the system has CUDA10.2 installed.
Feb 17 2020
- In order to avoid the bug in PR44587, one needs to build with >9.0.
- With CUDA toolkit 10.2, building the trunk will fail because 10.0.0 does not support it yet.
Feb 14 2020
I am not sure I understand. Do we need to modify stuff outside of /openmp? I was hoping it is our CMake that can be adjusted to make this work as described earlier. TBH, he warning is even not my biggest problem. As long as we get a libomptarget.bc we should be fine.
It turns out that having the warning message also affects the C_SUPPORTS_FPIC test in cmake/modules/HandleLLVMOptions.cmake. As a result, cmake thinks that -fPIC is not supported. Eventually, it leads to error in libclang-cpp.so.
Thanks for all the comments. It makes sense to keep the warning there before any ptx65 features are added. The warning should also apply to both the CUDA and OpenMP compile paths. As a result, I will pursue to ignore the warning in the build of libomp (i.e. libomp_check_linker_flag function in LibompCheckLinkerFlag.cmake). I think it is less pervasive and also can avoid similar occurrence when a new version of CUDA toolkit is available.
Feb 13 2020
Feb 12 2020
Feb 11 2020
Feb 3 2020
Change requires unified_address status to partial.
Jan 23 2020
Jan 22 2020
Address review comments and rebase.
Jan 17 2020
Jan 16 2020
Jan 6 2020
Jan 3 2020
Jan 2 2020
Update based on suggestion to simply the check and rebase.
Dec 30 2019
Dec 28 2019
Nov 22 2019
Nov 6 2019
Nov 5 2019
Sep 4 2019
Aug 9 2019
Aug 1 2019
Looks fine to me.
Jul 29 2019
Jul 10 2019
Jul 9 2019
May 2 2019
It looks good to me.
It looks good to me.
Feb 21 2019
Feb 19 2019
The change looks okay to me.