summaryrefslogtreecommitdiffstats
path: root/Modules/Compiler
Commit message (Collapse)AuthorAgeFilesLines
* Cray: Enable explicit Fortran preprocessing for Ninja generatorBrad King2021-03-051-0/+4
| | | | | | | | | Cray 11.0 adds support for preprocessing with output written to a specified file (instead of always next to the source). Use it to enable Cray Fortran with the Ninja generator. Patch-by: James Elliott Fixes: #20731
* Android: Do not use gold for ndk >= r22Haibo Huang2021-03-031-1/+1
| | | | Fixes: #21772
* PGI: Explicitly specify CMAKE_CXX98_STANDARD_COMPILE_OPTIONRobert Maynard2021-02-241-0/+2
| | | | | | | | | The PGI ( and NVIDIA HPC ) compilers default C++ standard level are based on the GCC system headers it is compiling against. Therefore on newer platforms the default C++ level will be >= 11 and requesting C++98 compilation mode will fail as no explicit flag will be set.
* NAG: Fix using Fortran modules from their output directoryBrad King2021-02-221-0/+1
| | | | | | | | | | | | | The NAG Fortran compiler's `-mdir` flag sets the module output directory but does not add the directory to the search path for using modules. This is inconsistent with other compilers like the GNU Fortran compiler's `-J` flag that does both. In order to make these consistent, add the module output directory with a `-I` flag on the NAG Fortran compiler so that it will be searched when using modules too. We already do this for the XL Fortran compiler since commit 210b0b99a9 (XL: Fix using Fortran modules from their output directory, 2020-02-28, v3.18.0-rc1~640^2~1).
* IntelLLVM: Make explicit Fortran preprocessing under Ninja more robustBrad King2021-02-181-2/+10
| | | | | | | | | Tell the Fortran compiler to write preprocessor output directly to a file, as we do for the GNU compiler. The previous "redirect stdout" approach could break during ABI detection with some `mpif90` wrappers that add version information to stdout when called with `-v`. Issue: #21828
* Merge branch 'backport-intel-fortran-preprocess'Brad King2021-02-181-2/+10
|\
| * Intel: Make explicit Fortran preprocessing under Ninja more robustBrad King2021-02-181-2/+10
| | | | | | | | | | | | | | | | | | Tell the Fortran compiler to write preprocessor output directly to a file, as we do for the GNU compiler. The previous "redirect stdout" approach could break during ABI detection with some `mpif90` wrappers that add version information to stdout when called with `-v`. Fixes: #21828
* | IntelLLVM: Remove incomplete C17 supportBrad King2021-02-151-8/+3
| | | | | | | | | | CMake does not yet model support for C17. Avoid possible confusion by removing the settings for IntelLLVM pending a full implementation.
* | IAR: add support for the STM8 compilerFelipe Torrezan2021-02-125-2/+16
| |
* | Merge topic 'IntelLLVM-no-imsvc' into release-3.20Brad King2021-02-111-1/+0
|\ \ | | | | | | | | | | | | | | | | | | e5563e592f IntelLLVM: Remove unsupported -imsvc system include flag Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5795
| * | IntelLLVM: Remove unsupported -imsvc system include flagwilliam.r.dieter2021-02-101-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | `clang-cl` supports the `-imsvc` flag to tell the compiler an include directory is intended for system paths. `icx` does not accept this flag, even on MSVC platforms, so do not tell CMake that it exists. Fixes: #21801 Signed-off-by: william.r.dieter <william.r.dieter@intel.com>
* | | Merge topic 'clang-imsvc'Brad King2021-02-101-1/+0
|\ \ \ | |/ / |/| / | |/ | | | | | | | | 2fc5e5dba9 Clang: Use -imsvc for system include only with MSVC-like front-end Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: Thomas Bernard <thomas@famillebernardgouriou.fr> Merge-request: !5792
| * Clang: Use -imsvc for system include only with MSVC-like front-endBrad King2021-02-091-1/+0
| | | | | | | | | | | | | | | | | | | | In commit bb61c2d024 (Clang: use -imsvc for system include dirs when running on Windows, 2020-09-16, v3.19.0-rc1~162^2) we added `-imsvc` for all Clang compilers targeting the MSVC ABI. However, the option only exists for the MSVC-like front-end. The GNU-like front-ends use `-isystem`. Fixes: #21789
| * Merge topic 'ispc-system-includes' into release-3.19Brad King2020-12-101-2/+0
| |\ | | | | | | | | | | | | | | | | | | 8da25e4a3c ISPC: Treat system includes as '-I' includes Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5591
* | | IntelLLVM: Add support for Intel LLVM-based compilersWilliam R. Dieter2021-01-286-0/+297
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | NVHPC: Add support for NVIDIA HPC SDK compilers based on PGITin Huynh2021-01-275-0/+33
| | | | | | | | | | | | | | | | | | | | | Identify the compilers as `NVHPC` to distinguish it from the older PGI compilers from which they evolved, and from other `NVIDIA` compilers. Fixes: #20887
* | | BinUtils: prefer bin utils matching the compiler version extensionThomas Bernard2021-01-111-0/+8
| | |
* | | Merge topic 'cpp23'Brad King2020-12-103-31/+18
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 9f3c70a333 CUDA, CXX, OBJCXX: C++23 support with Clang 12 af7e1545c8 CUDA, CXX: Remove HAS_FULL_SUPPORT for C++17 and 20 Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5576
| * | | CUDA, CXX, OBJCXX: C++23 support with Clang 12Raul Tambre2020-12-082-0/+14
| | | | | | | | | | | | | | | | | | | | Clang 12 landed initial support for C++23 language mode flag -std={c|gnu}++2b in commit 6627a3c2873fdf7ccba1a1573371079be48b36e8.
| * | | CUDA, CXX: Remove HAS_FULL_SUPPORT for C++17 and 20Raul Tambre2020-12-083-31/+4
| | | | | | | | | | | | | | | | | | | | | | | | CMake has no features for C++ versions past 14 and it seems unlikely we'd want to add any. Remove the related code.
* | | | Merge topic 'ispc-system-includes'Brad King2020-12-101-2/+0
|\ \ \ \ | | |_|/ | |/| | | | | | | | | | | | | | | | | | 8da25e4a3c ISPC: Treat system includes as '-I' includes Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5591
| * | | ISPC: Treat system includes as '-I' includesRobert Maynard2020-12-091-2/+0
| | | | | | | | | | | | | | | | ISPC doesn't have specific syntax for system includes.
* | | | Merge topic 'remove-partial-intel-compiler-support'Brad King2020-12-082-14/+0
|\ \ \ \ | |_|/ / |/| | / | | |/ | |/| | | | | | | | | | | | | 41b69348a5 Revert "Intel: Add Intel DPC++ compiler identification" f0babb53b3 Revert "Intel: Add Intel Clang compiler identification" Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: Axel Huebl <axel.huebl@plasma.ninja> Merge-request: !5583
| * | Revert "Intel: Add Intel DPC++ compiler identification"Brad King2020-12-071-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revert commit 887f3a88a6 (Intel: Add Intel DPC++ compiler identification, 2020-09-21, v3.19.0-rc1~124^2). The compiler has already been released, and is more usable with CMake by pretending to be upstream Clang than by identifying it as a compiler for which we have not implemented support. Fixes: #21551
| * | Revert "Intel: Add Intel Clang compiler identification"Brad King2020-12-071-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revert commit 5c3a93ab88 (Intel: Add Intel Clang compiler identification, 2020-09-29, v3.19.0-rc1~68^2). The compiler has already been released, and is more usable with CMake by pretending to be upstream Clang than by identifying it as a compiler for which we have not implemented support. Issue: #21551
* | | Merge topic 'explicit-LANGUAGE-flag'Brad King2020-12-0411-0/+18
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 48aac247e9 Compile with explicit language flag when source LANGUAGE property is set 2e67a75acd Embarcadero: Simplify addition of -P flag for C++ Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5522
| * | | Compile with explicit language flag when source LANGUAGE property is setBrad King2020-12-0211-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change was originally made by commit 74b1c9fc8e (Explicitly specify language flag when source LANGUAGE property is set, 2020-06-01, v3.19.0-rc1~722^2), but it was reverted by commit 30aa715fac (Revert "specify language flag when source LANGUAGE property is set", 2020-11-19) to restore compatibility with pre-3.19 behavior. Implement the change again, but add policy CMP0119 to make this change while preserving compatibility with existing projects. Note that the `Compiler/{Clang,Intel,MSVC}-CXX` modules do not need to specify `-TP` for their MSVC-like variants because we already use the flag in `CMAKE_CXX_COMPILE_OBJECT`. Similarly for `Compiler/XL-CXX` and `Platform/Windows-Embarcadero`. Note also that this does not seem possible to implement for XL C. Even with `-qsourcetype=c`, `xlc` complains about an unknown suffix: `1501-218 (W) file /.../AltExtC.zzz contains an incorrect file suffix`. It returns non-zero even with `-qsuppress=1501-218`. Co-Author: Robert Maynard <robert.maynard@kitware.com> Fixes: #14516, #20716
* | | | NVIDIA-CUDA: rely on new capabilities for deps generationMarc Chevrier2020-12-021-4/+3
| | | |
* | | | Merge topic 'ti-c-only-standard'Brad King2020-12-021-3/+3
|\ \ \ \ | |/ / / |/| / / | |/ / | | | | | | | | | 8eeddb1f0a Compiler/TI: Fix C standard flags in C-only project Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5558
| * | Compiler/TI: Fix C standard flags in C-only projectAdam Weisi2020-12-011-3/+3
| | | | | | | | | | | | Use our compiler architecture variable for C rather than CXX.
* | | Merge topic 'makefiles-compiler-deps-optims'Brad King2020-11-3026-15/+167
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2c71d051fa Makefiles Generators: use compiler for dependencies generation afd0f6785d Refactoring: Abstract Makefile line continuation format b6068ce407 Refactoring: enhance include file filtering 3401403f69 Refactoring: Introduce place-holder for dependency target. a97c41bf8b Refactoring: Makefiles Generators: Add support for various depends scanners Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: Brad King <brad.king@kitware.com> Merge-request: !5528
| * | Makefiles Generators: use compiler for dependencies generationMarc Chevrier2020-11-2917-0/+152
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Each source compilation generates a dependencies file. These dependencies files are consolidated in one file per target. This consolidation is done as part of command 'cmake -E cmake_depends` launched before evaluation of makefile dependency graph. The consolidation uses the same approach as `CMake` dependencies management. Fixes: #21321
| * | Refactoring: Introduce place-holder for dependency target.Marc Chevrier2020-11-2814-15/+15
| |/ | | | | | | | | | | | | | | These changes are in preparation of compiler generated dependencies support for Makefiles generators * compiler output and dependency target can be different for Makefiles generators * resolve inconsistency naming for dependency file place-holder
* | Modules: Rename Internal/CMake{CheckCompiler => TryCompilerOrLinker}FlagRobert Maynard2020-11-251-1/+0
|/ | | | | | | | Rename the `CheckPIESupported` helper functions so that they don't clobber other internal functions. Also rename them to document they can't be unified with `CheckCompilerFlag`. Fixes: #21497
* Revert "specify language flag when source LANGUAGE property is set"Brad King2020-11-1912-24/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Revert commit 74b1c9fc8e (Explicitly specify language flag when source LANGUAGE property is set, 2020-06-01, v3.19.0-rc1~722^2) and the lookup tables from its two immediate ancestors. The purpose of that change was to convert an explicit `LANGUAGE` source file property into an explicit language specification compiler flag like `-x c`. This seems reasonable since the property is documented as meaning "indicate what programming language the source file is". It is also needed to help compilers deal with non-standard source file extensions they don't recognize. However, some projects have been setting `LANGUAGE C` on `.S` assembler source files to mean "use the C compiler". Passing `-x c` for them breaks the build because the `.S` sources are not written in C. These projects should be updated to use `enable_language(ASM)`, for which CMake often chooses the C compiler as the assembler when using toolchains that support it (which would have to be the case for projects using the approach). Revert the change for now to preserve the old behavior for such projects. We can re-introduce it with a policy in a future version of CMake. Fixes: #21469 Issue: #14516, #20716
* CUDA: Enable support on QNXjanbernloehr2020-11-021-1/+1
| | | | | | | | | | | This fixes the following two issues with the CUDA support on QNX: * cuda target name is not derived correctly (should be `aarch64-qnx`). * linking `cudart` must not be linked against `rt`, `dl`, `pthread`. This enables to use cmake's native cuda support on QNX. Fixes: #21381
* Merge topic 'correct_msvc_cuda_flag_warning' into release-3.19Brad King2020-10-271-4/+11
|\ | | | | | | | | | | | | 2b0d3c3524 CUDA: Use MSVC version to determine supported C++ standard levels Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5423
| * CUDA: Use MSVC version to determine supported C++ standard levelsRobert Maynard2020-10-261-4/+11
| | | | | | | | Fixes: #21335
* | IAR: Use .o object file extension with IAR-Ilink toolchainsFelipe Torrezan2020-10-151-0/+1
|/ | | | | The compiler default extension for its objects is `.o`. Prefer that over `.obj`.
* Intel: Add Intel Clang compiler identificationHarini Chilamantula2020-09-291-0/+7
| | | | | The compiler identifies itself with the `__INTEL_CLANG_COMPILER` preprocessor definition.
* CUDA: Clang separable compilationRaul Tambre2020-09-242-0/+2
| | | | | | | | | | | | For NVCC the compiler takes care of device linking when passed the "-dlink" flag. Clang doesn't support such magic and requires the buildsystem to do the work that NVCC does behind the scenes. The implementation is based on Bazel's device linking documentation: https://github.com/tensorflow/tensorflow/blob/7cabcdf073abad8c46e9dda62bb8fa4682d2061e/third_party/nccl/build_defs.bzl.tpl#L259 Closes: #20726
* Intel: Add Intel DPC++ compiler identificationHarini Chilamantula2020-09-221-0/+7
| | | | | The compiler identifies itself with the `__INTEL_DPCPP_COMPILER__` preprocessor definition.
* Compiler/TI: Add std options for C++14Josef Angstenberger2020-09-201-4/+22
| | | | | The TI compiler does either support C++98 or C++14, but not both at the same time.
* Compiler/TI: Add std options for C++98Josef Angstenberger2020-09-201-0/+51
| | | | | | | | The TI compiler does not support C++98, only C++03 (based on manual of current version). This change sets the C++98 option to C++03 based on the fact that it is done this way for the SunPro compiler already.
* Compiler/TI: Add std options for C11Josef Angstenberger2020-09-201-0/+11
|
* Compiler/TI: Check default C standardJosef Angstenberger2020-09-202-0/+19
|
* Compiler/TI: Check compiler version for C99 supportJosef Angstenberger2020-09-201-4/+35
|
* Compiler/TI: Fix definition of std optionsJosef Angstenberger2020-09-201-4/+4
| | | | | | | | - The compile option variable has to be defined as list. - The compiler works in relaxed ANSI mode by default. Strict ANSI has to be explicitly set additionally to the language standard.
* Compiler/TI: Avoid generic variable name in macroJosef Angstenberger2020-09-201-8/+7
| | | | | | | | | | In commit a548a52230 (Compiler/TI: Refactor C/CXX to use a common file, 2020-07-11) a variable named `prefix` has been introduced. It is set in the callers namespace because it was defined inside a macro, not a function. Avoid such generic variable name.
* Clang: use -imsvc for system include dirs when running on WindowsAndrew Fuller2020-09-161-0/+1
| | | | Fixes #17808
generated by cgit v0.12 at 2025-01-07 21:27:23 (GMT)