CMake merge requestshttps://gitlab.kitware.com/cmake/cmake/-/merge_requests2024-03-26T00:00:57-04:00https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9368IntelLLVM: Revert accidental use of -external:I with Fortran compilers2024-03-26T00:00:57-04:00Brad KingIntelLLVM: Revert accidental use of -external:I with Fortran compilersIn !8722 this flag was added for the C
and C++ compilers, but was accidentally added for Fortran too. Remove
it for the latter, as it is unsupported.
Issue: #25807
Backport: releaseIn !8722 this flag was added for the C
and C++ compilers, but was accidentally added for Fortran too. Remove
it for the latter, as it is unsupported.
Issue: #25807
Backport: release3.29.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/9170FindMPI: add IntelLLVM MPI wrappers2024-01-22T09:18:34-05:00Eisuke KawashimaFindMPI: add IntelLLVM MPI wrappersIntel MPI library now provides `mpiicx`, `mpiicpx`, and `mpiifx` wrappers, which respectively use `icx`, `icpx`, and `ifx` by default.
<https://www.intel.com/content/www/us/en/developer/articles/guide/download-documentation-intel-oneapi...Intel MPI library now provides `mpiicx`, `mpiicpx`, and `mpiifx` wrappers, which respectively use `icx`, `icpx`, and `ifx` by default.
<https://www.intel.com/content/www/us/en/developer/articles/guide/download-documentation-intel-oneapi-toolkits-components.html> >
<https://d1hdbi2t0py8f.cloudfront.net/mpi-docs/mpi_docs_2024.0.0.zip>3.29.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/9001VS: Add support for using Intel oneAPI Fortran compiler in .vfproj files2024-03-28T18:44:23-04:00Brad KingVS: Add support for using Intel oneAPI Fortran compiler in .vfproj filesAdd a `fortran={ifort,ifx}` field to `CMAKE_GENERATOR_TOOLSET` to
specify which Intel Fortran compiler to use.
Fixes: #25427Add a `fortran={ifort,ifx}` field to `CMAKE_GENERATOR_TOOLSET` to
specify which Intel Fortran compiler to use.
Fixes: #254273.29.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/8722IntelLLVM: support marking include paths as SYSTEM directories2024-03-24T15:07:54-04:00Ben BoeckelIntelLLVM: support marking include paths as SYSTEM directoriesSee: https://discourse.cmake.org/t/icx-on-windows-supports-external-i/8739
---
I've not been able to find documentation for this. I've sent out queries about it though.See: https://discourse.cmake.org/t/icx-on-windows-supports-external-i/8739
---
I've not been able to find documentation for this. I've sent out queries about it though.3.29.0https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8764IntelLLVM: Suppress -Rdebug-disables-optimization on debug builds2023-09-08T08:56:45-04:00Bram MetschIntelLLVM: Suppress -Rdebug-disables-optimization on debug buildsIntelLLVM 2023.0.0 and above emit this remark if `-g` is used without
any `-O<level>` flag, which is our default behavior. Add another flag
to suppress the remark.
Topic-rename: IntelLLVM-debug-flagsIntelLLVM 2023.0.0 and above emit this remark if `-g` is used without
any `-O<level>` flag, which is our default behavior. Add another flag
to suppress the remark.
Topic-rename: IntelLLVM-debug-flags3.28.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/8505IntelLLVM: Use compiler driver as linker for MODULE libraries too2023-05-26T09:25:57-04:00William R. DieterIntelLLVM: Use compiler driver as linker for MODULE libraries tooSince !6866 we default to the compiler
driver as linker for executables, shared libraries, and static
libraries. Not doing so for shared modules was an oversight. Copying
the shared library command line for shared modules fixes the pro...Since !6866 we default to the compiler
driver as linker for executables, shared libraries, and static
libraries. Not doing so for shared modules was an oversight. Copying
the shared library command line for shared modules fixes the problem
(and also is what we do for MSVC).
The MSVC linker is fine for many cases, however it does not support GPU
offload code generated by the IntelLLVM compilers. Using the compiler
driver as linker, or at least a linker that understands the object
format, is required for linking shared modules that use GPU offload
(e.g., with SYCL or OpenMP).
Signed-off-by: William R. Dieter <william.r.dieter@intel.com>3.27.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/8132gitlab-ci: add jobs testing Intel 2023.0.0 compilers on Linux2023-01-28T06:24:27-05:00Brad Kinggitlab-ci: add jobs testing Intel 2023.0.0 compilers on LinuxNote that the classic compiler version is 2021.8.0, but we still
have it in the 2023.0.0 base image.Note that the classic compiler version is 2021.8.0, but we still
have it in the 2023.0.0 base image.3.26.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/8041IntelLLVM: Avoid finding not-yet-supported icpx on Windows2023-03-08T11:49:36-05:00scivisionIntelLLVM: Avoid finding not-yet-supported icpx on WindowsIntel oneAPI 2023.0 added the `icpx` compiler front-end on Windows.
It uses a GNU-like command-line, and is not yet supported by CMake.
Avoid finding `icpx` as the CXX compiler on Windows until support
is added.
<details><summary>Origin...Intel oneAPI 2023.0 added the `icpx` compiler front-end on Windows.
It uses a GNU-like command-line, and is not yet supported by CMake.
Avoid finding `icpx` as the CXX compiler on Windows until support
is added.
<details><summary>Original Description</summary>
This works around #24266 by first looking for icx on Windows before icpx. This allows if someday oneAPI Windows decides to only have icpx.
This also retains current MSVC-like driver default for those user projects relying on this default.
A long-term preference by me would be for CMake to also support icpx on Windows (perhaps
!8032), but this maintaining of icx driver default on Windows is also important.
The second commit documents which compiler drivers are supported.
</details>
Fixes: #24266
Issue: #24314
Backport: release
Topic-rename: IntelLLVM-no-icpx-on-Windows3.24.4Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/8069IntelLLVM: Avoid unnecessary -Qstd=c++11 flag on Windows2023-01-13T08:43:35-05:00Brad KingIntelLLVM: Avoid unnecessary -Qstd=c++11 flag on WindowsThe IntelLLVM compiler, for compatibility with MSVC on Windows, always
runs with support for at least C++14. The `-Qstd=c++11` flag just
causes a warning that it is unused.
Fixes: #24316
Backport: releaseThe IntelLLVM compiler, for compatibility with MSVC on Windows, always
runs with support for at least C++14. The `-Qstd=c++11` flag just
causes a warning that it is unused.
Fixes: #24316
Backport: release3.25.2Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/7533IntelLLVM: Enable IPO for Linux and Windows2022-08-04T09:37:50-04:00William R. DieterIntelLLVM: Enable IPO for Linux and WindowsThe first commit in the sequence updates Windows-IntelLLVM so that linking flags are passed to the compiler rather than the linker. Linker flags that the compiler does not understand and need to go to the linker will now need to be wrap...The first commit in the sequence updates Windows-IntelLLVM so that linking flags are passed to the compiler rather than the linker. Linker flags that the compiler does not understand and need to go to the linker will now need to be wrapped, as they are with clang and some other compilers, so that they pass through to the linker.
This change broke the `ModuleDefinition` test because the /DEF option provided in the test did not get wrapped. Adding the `.def` file to the sources for the test library caused the `.def` file to be passed correctly. The other Windows-MSVC platforms in the test pass the `.def` file by adding a link flag property which seems like a lower level solution.
The IntelLLVM compilers need the OpenMP flag to be passed to the linker under some circumstances -- for example, when doing target offload. That was previously not possible, because the link flags were passed directly to the linker rather than the compiler. Since it is now possible, I added the OpenMP flag to the linker flags in FindOpenMP.
In addition to setting the variables saying that IntelLLVM supports IPO, IPO wants to use `ar` and `ranlib` to build static libraries. Previously, IntelLLVM did not have a FindBinUtils, and it seemed to be working find with the normal `tools `ar` and `ranlib` that CMake found. For non-IPO (and non-target offload) cases, these tools are the expected ones to use, but for IPO (and target offload) the .o files are in a non-standard format that require the LLVM versions of `ar` and `ranlib`. So, I added `FindBinUtils-IntelLLVM` to help IPO find the right tools.
The last issue is that in building CMake itself, the `-stack` parameter is added to the link flags to limit stack size. `icx.exe` does not recognize the flag, prints a warning, and ignores the flag. I added the wrapper prefix so icx send the `-stack` option to the linker, hoping it would be in a way that would work for any platform that needs to wrap linker flags passed to the compiler.
I tested building cmake on Ubuntu Linux 20.04.1, Windows Server 2022 Datacenter 21H2, and Windows 10 Enterprise with IPO, OpenMP, and MPI tests enabled, configuring with:
```
cmake -G Ninja -DCMAKE_INSTALL_PREFIX=${HOME}/ws/usr -DCMAKE_BUILD_TYPE=release ../cmake "-DCMake_TEST_IPO_WORKS_C:BOOL=ON" "-DCMake_TEST_IPO_WORKS_CXX:BOOL=ON" "-DCMake_TEST_IPO_WORKS_Fortran:BOOL=ON" -DCMake_TEST_FindOpenMP:BOOL=ON -DCMake_TEST_FindOpenMP_C:BOOL=ON -DCMake_TEST_FindOpenMP_CXX:BOOL=ON -DCMake_TEST_FindOpenMP_Fortran:BOOL=ON -DCMake_TEST_FindMPI:BOOL=ON -DCMake_TEST_FindMPI_C:BOOL=ON -DCMake_TEST_FindMPI_CXX:BOOL=ON -DCMake_TEST_FindMPI_Fortran:BOOL=ON
```
All the tests passed. I also tested building with MSVC on Windows and gcc 9.3 on Linux and tests passed that way as well.
Fixes: #23741, #231493.25.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/7758Intel/IntelLLVM: Fortran has distinct "-Werror"-like flag2023-04-03T09:36:36-04:00scivisionIntel/IntelLLVM: Fortran has distinct "-Werror"-like flag!7187 introduced the greatly appreciated `COMPILE_WARNING_AS_ERROR` property.
However, the Intel and IntelLLVM compilers on non-Windows systems cannot use `-Werror` or `-Werror-all`.
The corresponding flags for Fortran are `-warn errors`...!7187 introduced the greatly appreciated `COMPILE_WARNING_AS_ERROR` property.
However, the Intel and IntelLLVM compilers on non-Windows systems cannot use `-Werror` or `-Werror-all`.
The corresponding flags for Fortran are `-warn errors` or `/warn:errors`
Backport: release
Topic-rename: Intel-Fortran-warn-errors3.24.3Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/7270gitlab-ci: add jobs testing Intel 2022.1.0 compilers on Linux2022-05-17T08:46:24-04:00Brad Kinggitlab-ci: add jobs testing Intel 2022.1.0 compilers on LinuxNote that the classic compiler version is 2021.6.0, but we still
have it in the 2022.1.0 base image.Note that the classic compiler version is 2021.6.0, but we still
have it in the 2022.1.0 base image.3.24.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/6962gitlab-ci: add jobs testing Intel 2021.3, 2021.4, and 2022.0 compilers on Linux2022-02-09T08:57:52-05:00Brad Kinggitlab-ci: add jobs testing Intel 2021.3, 2021.4, and 2022.0 compilers on LinuxNote that the classic compiler version is 2021.5.0, but we still
have it in the 2022.0.2 base image.Note that the classic compiler version is 2021.5.0, but we still
have it in the 2022.0.2 base image.3.24.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/7057IRSL: Add paths for Intel oneAPI compilers on Linux2022-03-10T08:41:42-05:00Attila KrasznahorkayIRSL: Add paths for Intel oneAPI compilers on LinuxAdded the location of the [oneAPI](https://www.intel.com/content/www/us/en/developer/tools/oneapi/overview.html) runtime libraries. They are stored in a slightly different place with oneAPI than they used to be in Parallel Studio.
The l...Added the location of the [oneAPI](https://www.intel.com/content/www/us/en/developer/tools/oneapi/overview.html) runtime libraries. They are stored in a slightly different place with oneAPI than they used to be in Parallel Studio.
The list of libraries will also need to be revised in a further step, but I didn't want to bite off more than I could chew.
P.S. Note that the previous path **is** correct for PSXE 2019 for instance. I'm just adding that here, because at first I thought I found a bug in the code. But instead it's just that the code was not updated for oneAPI yet.
Fixes: #23310
Backport: release
Topic-rename: irsl-oneapi-linux3.23.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/6866IntelLLVM: Set linker to compiler driver for Windows2023-05-25T13:17:39-04:00William R. DieterIntelLLVM: Set linker to compiler driver for WindowsFor IntelLLVM, linking with the compiler driver is preferred over using
the linker directly. This is especially true when doing offload to a
target accelerator, which can produce object files that the regular
linker will not handle prop...For IntelLLVM, linking with the compiler driver is preferred over using
the linker directly. This is especially true when doing offload to a
target accelerator, which can produce object files that the regular
linker will not handle properly.
Windows-IntelLLVM relies on Windows-MSVC.cmake for many definitions.
This commit does not change that, but does override the MSVC defaults
for linking executables, shared libraries, and static libraries so that
CMake will use the compiler driver instead of the linker.
Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
Topic-rename: IntelLLVM-windows-link-with-driver3.23.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/6811Tests: In RunCMake.GeneratorToolset accept Intel platform toolsets2021-12-20T09:21:36-05:00William R. DieterTests: In RunCMake.GeneratorToolset accept Intel platform toolsetsThe RunCMake.GeneratorToolset test expected platform toolsets to have a
name beginning with 'v' followed by one or more decimal digits, as all
the Microsoft platform toolsets follow that naming convention.
The Intel platform toolsets beg...The RunCMake.GeneratorToolset test expected platform toolsets to have a
name beginning with 'v' followed by one or more decimal digits, as all
the Microsoft platform toolsets follow that naming convention.
The Intel platform toolsets begin with "Intel" and have various
additional strings depending on the compiler version.
This change accepts the toolsets delivered by Intel in addition to those
from Microsoft.
Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
Topic-rename: test-vsnormal-allow-intel3.23.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/6964IntelLLVM: Add dependencies on system header files on Windows2022-03-04T12:36:45-05:00William R. DieterIntelLLVM: Add dependencies on system header files on WindowsIn !5594 the IntelLLVM depfile generation flags were taken from `Platform/Windows-Intel-C`. Those flags were added by !2893, which forgot to account for commit 6d74e7870b8804a5af0bc395a9fbb45c1b3d26a4 (Ninja: Add dependencies on system-...In !5594 the IntelLLVM depfile generation flags were taken from `Platform/Windows-Intel-C`. Those flags were added by !2893, which forgot to account for commit 6d74e7870b8804a5af0bc395a9fbb45c1b3d26a4 (Ninja: Add dependencies on system-provided header files).
The `-QMD` option generates Makefile dependencies. The `-QMMD` option
generates Makefile dependencies, but excludes system header files.
Part of the BuildDepends test includes a header, cmake_pch.hxx, that
includes a second header, zot_pch.hxx. The test builds a pch file for
cmake_pch.hxx, touches zot_pch.hxx, then verifes that cmake_pch.hxx.pch
is regenerated based on the dependencies.
The cmake_pch.hxx contains `#pragma system_header` before it includes
zot_pch.hxx. `#pragma system_header` indicates that the portion of the
file following the pragma is to be treated as a system header.
When `-QMMD` is used to generate dependencies, the `#include` of
zot_pch.hxx is ignored because it `-QMMD` says to ignore system headers.
Using `-QMD` instead uses all headers when generating dependencies
and causes this test to pass. The Clang configuration in
Platform/Windows-Clang.cmake also uses the `-MD` option for generating
pre-compiled headers, instead of `-MMD`.
Backport: release
Topic-rename: IntelLLVM-depfile-flags3.21.6Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/6806VS: Fix detecting icx.exe with Intel Compiler toolsets newer than 20212022-02-01T12:36:18-05:00William R. DieterVS: Fix detecting icx.exe with Intel Compiler toolsets newer than 2021Update CMAKE_VS_PLATFORM_TOOLSET matching rules for Intel compilers.
The logic added by !5579 matches a specific toolset known to be the `icx.exe` compiler, and
assumes all other Intel C++ compilers (that are not DPC++) must be
`icl.exe...Update CMAKE_VS_PLATFORM_TOOLSET matching rules for Intel compilers.
The logic added by !5579 matches a specific toolset known to be the `icx.exe` compiler, and
assumes all other Intel C++ compilers (that are not DPC++) must be
`icl.exe`.
Since `icx.exe` is officially replacing `icl.exe`, use a regex that
matches the now-fixed set of toolsets known to use `icl.exe`. Any other
Intel C++ compiler will be assumed to be `icx.exe`.
Backport: release
Topic-rename: vs-intel-oneapi-toolset3.21.5Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/6740IntelLLVM: Enable Fortran module rebuild avoidance in Makefile generators2022-02-01T12:35:00-05:00Brad KingIntelLLVM: Enable Fortran module rebuild avoidance in Makefile generatorsThe Makefile generators use an internal `cmake -E cmake_copy_f90_mod`
tool to avoid rebuilding module consumers when the `.mod` content
changes only in a trivial way (e.g. the time it was built). This is
done with logic specific to each...The Makefile generators use an internal `cmake -E cmake_copy_f90_mod`
tool to avoid rebuilding module consumers when the `.mod` content
changes only in a trivial way (e.g. the time it was built). This is
done with logic specific to each vendor's module file format. Enable
the "Intel" format support when using the IntelLLVM compiler (ifx) too.
Issue: #22922
Backport: release3.21.5Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/6719IntelLLVM: Use MSVC linker with MSVC frontend variant2022-02-01T12:34:29-05:00William R. DieterIntelLLVM: Use MSVC linker with MSVC frontend variantThe Intel compiler (pre-LLVM) expected xilink.exe and had special logic to
set xilink.exe. The newer LLVM-based compiler does not want xilink.exe.
link.exe works better for host code, and is the default, so change
the matching condition...The Intel compiler (pre-LLVM) expected xilink.exe and had special logic to
set xilink.exe. The newer LLVM-based compiler does not want xilink.exe.
link.exe works better for host code, and is the default, so change
the matching condition such that the old compiler matches (and gets
xilink.exe) and the new compiler gets the default link.exe it expects.
A better solution will be to use the compiler as the linker. A future
change will switch to compiler as linker by default, but that fix needs
more validation.
Backport: release
Topic-rename: IntelLLVM-no-xilink3.21.5Brad KingBrad King