Previously we used separate placeholders for builtin linker flags:
* CMAKE_<LANG>_LINK_FLAGS for EXECUTABLEs
* CMAKE_SHARED_LIBRARY_CREATE_<LANG>_FLAGS for SHARED libraries
* CMAKE_SHARED_MODULE_CREATE_<LANG>_FLAGS for MODULE libraries
These are now always replaced by the empty string, so drop them
from our rule variables.
The `CMAKE_{EXE,SHARED,MODULE,STATIC}_LINKER_FLAGS` variables are
not language-specific, so multiple languages' toolchains may disagree
about if/how to pass the flag through a compiler driver to the linker.
Furthermore, carrying the flag in public-facing variables allows projects
or users to change it even though it is required. Add policy CMP0197
to remove the flag from the public-facing variables and generate it
automatically instead:
* For command-line generators, add the `-machine:` flag to the
linker and archiver rule variables.
* For Visual Studio generators, we do not need to explicitly add the
link `-machine:` flag. MSBuild automatically adds it, and the new
behavior actually removes a duplicate we generated previously.
Issue: #21934
With IntelLLVM on Windows, we link using the compiler driver.
With MSVC on Windows, we invoke the linker directly. If we
use both in a single build tree, for separate languages,
the value of `CMAKE_LINK_DEF_FILE_FLAG` conflicts. Add a
per-language `CMAKE_<LANG>_LINK_DEF_FILE_FLAG` variable to
avoid the conflict. Preserve the language-agnostic variable
for compatibility with projects that reference it.
Fixes: #26005
This variable define how the link step is done. Possible values are:
* DRIVER: the compiler is used as driver for the link step
* LINKER: the linker is used directly for the link step.
The link flag wrapping added by commit 5d5a712303 (IntelLLVM: Pass
linker flags to the compiler when used as linker, 2022-05-27,
v3.25.0-rc1~344^2~4) is not needed with Visual Studio generators because
MSBuild invokes the linker directly. Furthermore, that commit omitted
wrapping of the per-config linker flags.
Revise the logic to add the link flag wrapping more precisely.
Fixes: #25533
Since commit 79921fb00c (IntelLLVM: Set linker to compiler driver for
Windows, 2021-10-19, v3.23.0-rc1~127^2) 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>
When linking an executable, DLL, or static library, the compiler sometimes
needs to see the linking options. Typically `<FLAGS>` is not passed
for linking, because some of the options are only used for compilation.
Previously, `<LINK_FLAGS>` was passed after the `/link` flag because
the compiler did not understand some of the linking options.
This change wraps the initial linker options borrowed from Windows-MSVC
individually, so that they are passed directly to the linker.
This change is helpful both for interprocedural optimization, which needs
to pass `-Qipo` to the compiler at link time, and for SYCL which needs
to pass `-fsycl` and possibly other options to the compiler at link time.
Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
In commit a90d2a9eed (IntelLLVM: Add support for Intel LLVM-based
compilers, 2020-11-02, v3.20.0-rc1~89^2~20) the IntelLLVM depfile
generation flags were taken from `Platform/Windows-Intel-C`. Those
flags were added by commit a624a3e1b3 (Ninja: Use deps=gcc for Intel
Compiler on Windows, 2019-01-30, v3.14.0-rc1~30^2), which forgot to
account for commit 6d74e7870b (Ninja: Add dependencies on
system-provided header files, 2016-03-15, v3.6.0-rc1~265^2).
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`.
Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
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>
Using a single ID 'IntelLLVM' for the suite of Intel compilers based on
the LLVM backend. The 'IntelLLVM' ID are used for C, C++, and Fortran.
Data Parallel C++ will be handled in a separate commit.
The C and C++ definitions are based on the Clang definitions. The Intel
LLVM-based C and C++ compilers are based on the Clang front end, so
existing Clang options are more likely to be a good match than options
for the older Intel compilers.
Fortran is based on the older Fortran front end with the LLVM backend.
It has a similar interface to the older versions, though many options
are shared with the C and C++ compilers.
Fixes: #21561
Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
