I was noticing that FindOpenMP was failing to find my openmp installation
on macos when building with a custom-compiled clang. Upon inspection it
appears that FindOpenMP is looking for `AppleClang` as a compiler
identification and the `Clang` case is only applicable for Win32.
Try to fix that by treating custom `Clang` on macos the same as
`AppleClang`.
If `OpenMP_C_FLAGS` contains `-Xclang -fopenmp`, the flag pair needs to
be preserved as a shell command fragment, and must not be split by
de-duplication with other `target_compile_options`.
Fixes: #24966
If `OpenMP_<lang>_INCLUDE_DIR` is defined, add it to the list of include
directories before checking flags. Previously, this variable was
ignored for all compilers but AppleClang, despite the documentation
mentioning it as one of the possible inputs.
Fixes: #24260
Replace old-style `file(APPEND .../CMake{Output,Error}.log)` logging
with calls to `message(CONFIGURE_LOG)` to record the steps in the
`CMakeConfigureLog.yaml` configure log instead.
Issue: #23200
`try_compile` and `try_run` now automatically log checks using them to
`CMakeConfigureLog.yaml`.
Add `LOG_DESCRIPTION` arguments to some `try_compile` calls to
replace the description previously written to the old logs.
Issue: #23200
Modify some additional modules that ship with CMake to use the new
SOURCES_FROM_* arguments to try_compile / try_run as added by commits
cb14ae2b87 (try_compile: Add SOURCE_FROM_{ARG,VAR}, 2022-09-21) and
611d801790 (try_compile: Add SOURCE_FROM_FILE, 2022-09-22). This covers
modules that need to read and alter a template source file, which were
not addressed in the previous commit.
Note that FindOpenACC.cmake does not actually need configure_file
functionality; it appears to have inherited the (gratuitous) use thereof
from FindOpenMP.cmake, with which its code bears significant similarity.
Modify most of the modules that ship with CMake to use the new
try_compile / try_run signatures added by commit aa9220d3a0
(try_compile: Add keyword-dispatched signature, 2022-09-02). This
improves debugging by each invocation using its own directory so that
the results of multiple invocations can be retained.
This does not cover any invocations which provide an entire project, as
that flavor of try_compile has not yet been updated.
c633bd76d8 Add linker prefix for "-stack" flag on MSVC builds
6823db0c5a Enable IPO for IntelLLVM compilers on Linux and Windows
adbffd204d Propagate OpenMP compiler flags to linker for IntelLLVM
3640842df2 Tests: Update ModuleDefinition for IntelLLVM MSVC Frontend Variant
5d5a712303 IntelLLVM: Pass linker flags to the compiler when used as linker
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !7533
When compiling for offload and in general when OpenMP is enabled while
compiling, it should also be enabled when linking.
Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
In commit 98314d536e (FindOpenMP: Use NO_DEFAULT_PATH where appropriate,
2017-11-15, v3.11.0-rc1~334^2) we added `NO_DEFAULT_PATH` so that it no
longer searches in `CMAKE_PREFIX_PATH`, but this also excludes searching
in system paths, which are needed on RISC-V platforms. Use more granular
exclusions instead.
Fixes: #23469
Since commit 2dbff623f9 (FindOpenMP: Save flags/libs in cache entries
each time they are detected, 2020-02-07, v3.17.0-rc1~10^2~1) we replace
both `OpenMP_${LANG}_FLAGS` and `OpenMP_${LANG}_LIB_NAMES` with detected
flags if either one is not set. That can overwrite user-provided flags.
Update the logic for C, CXX, and Fortran to initialize each
`OpenMP_${LANG}_{FLAGS,LIB_NAMES}` variable only if it has not already
been set by the user.
Fixes: #23743
It is found out for LCC to not specify all library search paths
when called by cmake_parse_implicit_link_info().
Because of that, FindOpenMP module can't find some libraries,
like libpthread. For this, we should analyze -print-search-dirs
output and append library paths to implicit link ones.
Divert LCC compiler as a new one, instead of treating it as GNU.
Since old times, Elbrus C/C++/Fortran Compiler (LCC) by MCST has been
passing checks for GNU compilers, so it has been identified as GNU.
Now, with intent of seriously upstreaming its support, it has been
added as a separate LCC compiler, and its version displays not a
supported GCC version, but LCC version itself (e.g. LCC 1.25.19 instead
of GNU 7.3.0).
This commit adds its support for detection, and also converts basically
every check like 'is this compiler GNU?' to 'is this compiler GNU or
LCC?'. The only places where this check is untouched, is where it
regards other platforms where LCC is unavailable (primarily non-Linux),
and where it REALLY differs from GNU compiler.
Note: this transition may break software that are already ported to
Elbrus, but hardly relies that LCC will be detected as GNU; still such
software is not known.
The Windows driver does not like the `-f` form of this option.
Note that we prefer `-Qiopenmp/-fiopenmp` over `-Qopenmp/-fopenmp` in
order to generate LLVM IR with parallelization information, which the
backend uses to generate parallelized code.
Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
The version is determined in two steps. First, the "spec date" is
detected and cached. Second, the date is converted to a version.
Move the second step out of the spec date cache guard condition
so that it runs every time even if the spec date is already cached.
Fixes: #19150
The HIP clang makes 2 passes when compiling HIP programs: the DEVICE
pass and the HOST pass. For openmp, the `-fopenmp` option is only
passed to the HOST compilation pass. Therefore, the small test that
CMake uses for OpenMP detection fails to compile, and CMake reports
failure to detect OpenMP support in the compiler. The suggested
solution is to add check for `__HIP_DEVICE_COMPILE__` macro defined by
HIP clang for the DEVICE pass to the OpenMP detection test.
In commit beb991110d (Remove now-unused code once used on IRIX,
2019-01-11, v3.14.0-rc1~167^2) we removed remnants of IRIX support.
Also remove remnants of MIPSpro compiler support.
The test code added by commit v3.12.0-rc1~411^2~1 (FindOpenMP: Verify in
test source that OMP library is linked, 2018-03-01) leaves an unused
variable warning. This breaks the check with `-Werror`. Remove the
variable and leave just the function call, which should still check that
the OMP library is linked.
Fixes: #18102
The change in commit v3.11.0-rc1~334^2 (FindOpenMP: Use NO_DEFAULT_PATH
where appropriate, 2017-11-15) broke partial support for Intel on Windows.
Since `OpenMP_${LANG}_IMPLICIT_LINK_DIRS` is empty for this compiler
the `find_library` call without `NO_DEFAULT_PATH` worked accidentally
in environments with the needed libraries in the search path already.
Fix support for Intel on Windows by simply removing our explicit search
for the `libiomp5md` library. In cases that it is needed, the compiler
already inserts metadata in `.obj` files to tell the MSVC linker to use
the library.
Suggested-by: Christian Pfeiffer <cpfeiffer@live.de>
Fixes: #17910
OpenMP libraries must always be found in the implicit linking
directories of a compiler when using the OpenMP compile flag. If a suitable OpenMP library is also found in for example some CMAKE_PREFIX_PATH, this can lead to the module finding the incorrect library.
On the other hand, CMAKE_PREFIX_PATH can't ever be a location that we
need to consider since the OpenMP compile flag would not work if we
needed to.
