summaryrefslogtreecommitdiffstats
path: root/Modules/Compiler
Commit message (Collapse)AuthorAgeFilesLines
* Merge topic 'intel-2021'Brad King2021-04-291-7/+16
|\ | | | | | | | | | | | | | | 9c479c7c40 IntelLLVM: Add special case for ifx 2021.1 version extraction b7193ab18f Intel: Update Classic compiler version detection for 2021 Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !6052
| * Intel: Update Classic compiler version detection for 2021Brad King2021-04-281-7/+16
| | | | | | | | | | | | | | The value of the `__INTEL_COMPILER` macro changed convention starting in version 2021. Fixes: #22120
* | Merge topic 'ARMClang-cpu-arch-flags'Brad King2021-04-281-26/+46
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | c4941b7e66 ARMClang: Do not automatically add cpu/arch compile or link options 0078db3888 ARMClang: Separate cpu/arch flags from preceding flags Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: Jaeden Amero <kitware@patater.com> Merge-request: !6035
| * | ARMClang: Do not automatically add cpu/arch compile or link optionsLingkai Dong2021-04-271-26/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The compile options `--march=<arch>` and `--mcpu=<cpu>` and the link option `--cpu=<cpu>` are automatically added by CMake based on `CMAKE_SYSTEM_PROCESSOR` or `CMAKE_SYSTEM_ARCH`. But this is not sufficient, because armclang also supports enabling or disabling features using `+<feature>`: -mcpu=<name>[+[no]<feature>+...] For example: -mcpu=cortex-a57+nocrypto+nofp+nosimd+crc (Reference: https://developer.arm.com/documentation/dui0774/k/Compiler-Command-line-Options/-mcpu?lang=en) The problem is, even if a project adds a flag with features it needs, CMake still adds flags, resulting in code that is compiled with wrong CPU features and unable to run. Add policy `CMP0123` to not automatically add compile or link options, and let projects set them instead. Co-Author: Brad King <brad.king@kitware.com> Fixes: #21173
| * | ARMClang: Separate cpu/arch flags from preceding flagsBrad King2021-04-271-3/+3
| | | | | | | | | | | | Suggested-by: Kim Kryger
* | | CUDA: Add CMAKE_CUDA_HOST_COMPILER support on Windows non-VS generatorsunknown2021-04-221-9/+5
|/ /
* | Fujitsu: Fix C90 standard flagsPaul Zehner2021-04-141-3/+3
| | | | | | | | | | Fix typos from commit 3c867cff4a (Fujitsu: Add support for the Fujitsu compiler in Trad mode, 2020-12-22).
* | Merge topic 'cuda-depfile-ccbin'Brad King2021-04-081-1/+9
|\ \ | |/ | | | | | | | | | | | | | | 8e38985db7 Makefiles: Fix dependency extraction with CUDA < 10.2 and host compiler Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: Raul Tambre <raul@tambre.ee> Acked-by: Robert Maynard <robertjmaynard@gmail.com> Merge-request: !5992
| * Makefiles: Fix dependency extraction with CUDA < 10.2 and host compilerBrad King2021-04-071-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 2c71d051fa (Makefiles Generators: use compiler for dependencies generation, 2020-10-18, v3.20.0-rc1~392^2) we invoke `nvcc` for CUDA < 10.2 a second time in order to generate a depfile. When `CMAKE_CUDA_HOST_COMPILER` is set, the second invocation is missing its `-ccbin=` option, even after refactoring in commit 8981e3e7cc (NVIDIA-CUDA: rely on new capabilities for deps generation, 2020-12-02, v3.20.0-rc1~362^2). Ideally we should move the `-ccbin=` flag into `Compiler/NVIDIA-CUDA`, but that will add `CMAKE_CUDA_HOST_COMPILER` support on Windows in command-line generators but not the Visual Studio generators. For now, add the flag to the depfile command specifically. Fixes: #22037
* | FujitsuClang: Add support for the Fujitsu compiler in Clang modeChuck Atkins2021-03-315-1/+33
| | | | | | | | | | | | This should be front end compatible with vanilla clang but giving it a unique identifier allows a project to pass additional options unique to Fujitsu and outside the scope of a CMake builtin.
* | Fujitsu: Add support for the Fujitsu compiler in Trad modeChuck Atkins2021-03-305-1/+132
| | | | | | | | Co-Author: Yuichiro Utsumi <utsumi.yuichiro@jp.fujitsu.com>
* | Merge topic 'cray-fortran'Brad King2021-03-081-0/+4
|\ \ | |/ | | | | | | | | | | ef513fe3d1 Cray: Enable explicit Fortran preprocessing for Ninja generator Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5882
| * 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
* | Merge topic 'android-r22'Brad King2021-03-031-1/+1
|\ \ | |/ | | | | | | | | | | | | | | | | 005e2cdfb0 Android: Do not use gold for ndk >= r22 ed7a87f270 Tests: Update RunCMake.Android for NDK r22 4950d35733 Help: Document CMAKE_ANDROID_NDK_VERSION variable 746906242d Android: Detect NDK version number Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5862
| * Android: Do not use gold for ndk >= r22Haibo Huang2021-03-031-1/+1
| | | | | | | | Fixes: #21772
* | IntelLLVM: C17 supportRaul Tambre2021-02-251-3/+7
| | | | | | | | Issue: #17755
* | GNU: C23 supportRaul Tambre2021-02-251-0/+5
| | | | | | | | Added in commit 9f936c861383dc69e0053e34315d5d0262a19e8f, released in 9.1.
* | GNU: C17 supportRaul Tambre2021-02-251-1/+6
| | | | | | | | | | | | | | Added in commit c76dc9c32d616eff1e0ae162042f1c0f8ca65fbf, released in 8.1. Set as default in the same commit. Issue: #17755
* | Clang: Default C standard doesn't depend on compatibility modeRaul Tambre2021-02-251-5/+1
| | | | | | | | MSVC compatibility mode doesn't affect the default standard.
* | Clang: Set standard flags according to frontend variantRaul Tambre2021-02-251-1/+1
| | | | | | | | | | | | They depend on the frontend not which compiler we're simulating. Fixes #21771.
* | Clang: MSVC-style C flagsRaul Tambre2021-02-251-4/+14
| | | | | | | | | | Support added in LLVM commit d087d805acb664e885e9c31a916f6cfa5dbc2186, will be released in Clang 13.
* | Clang: C23 supportRaul Tambre2021-02-251-0/+5
| | | | | | | | | | Added in LLVM commit d06f3917913d2558b771ccc48d838f8cd8993c01, released in Clang 9.0.
* | Clang: C17 default versionRaul Tambre2021-02-251-1/+1
| | | | | | | | | | | | | | Switched in LLVM commit 91cdbd521a38495c66e30636943563ca70d3c022, released in Clang 11. Issue: #17755
* | Clang: C17 supportRaul Tambre2021-02-251-0/+7
| | | | | | | | | | | | | | Added in LLVM commit 5b6c0f75e01571851b767dc63a3229c962f464f1, available since Clang 6. Issue: #17755
* | C23 supportRaul Tambre2021-02-251-0/+3
| |
* | C17 supportRaul Tambre2021-02-251-0/+3
| | | | | | | | Implements #17755.
* | Clang: Correct default C standards for ancient versionsRaul Tambre2021-02-251-1/+1
| | | | | | | | | | | | | | | | C11 was made default in LLVM commit ab506adf7d3ced6abcaf42f92de3d6cd15fa19e8, released in 3.5.2. C99 was made default in LLVM commit 17f76e04d244c80e70f1c81c94d4524b53d9772d, released in 2.1. It was flipped a few times between C89 and C99 during the 2.1 cycle, but the C89 default never made it into a release.
* | Clang: Correct C standards flags for ancient versionsRaul Tambre2021-02-251-15/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | C89, C99 flags in LLVM commit ff43821d5380ee38aff421701f1d461242b524ee. C90 flag in LLVM commit 229ce60fc9983df5f7e83e25fa6b5c0ca4d2b135. C1x flag in LLVM commit a686b5f8bf7b5a2ab636c0c2de5ad4c174aa33e0. C11 flag in LLVM commit 6784aeb9ef96e5735850fa7226ed0cb45cb82e75. Mark C90, C99 full support since 2.1. Might've been possibly a little later, but source spelunking that much back is difficult. Mark C11 full support since 3.0, which added _Static_assert in LLVM commit 3d9cbdc3e66e274d5d3cb94ce81a65478d9baae0.
* | Clang: C flags cleanupRaul Tambre2021-02-251-6/+4
| | | | | | | | Don't need to set the options to empty strings if not supported.
* | Merge topic 'cuda_clang_implicit'Brad King2021-02-251-2/+2
|\ \ | | | | | | | | | | | | | | | | | | 23753be1cc Clang/CUDA: Restore needed references to implicit link variables Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5855
| * | Clang/CUDA: Restore needed references to implicit link variablesRaul Tambre2021-02-241-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | In commit 4620cf77f2 (Clang: Remove unused CUDA implicit link variables, 2021-02-14) we removed some references. It turns out they are non-empty and necessary if using a non-scattered installation. Fixes: #21863
* | | Merge topic 'nvhpc-minor-fixes'Brad King2021-02-251-0/+2
|\ \ \ | |/ / |/| / | |/ | | | | | | | | 72efd95add PGI: Explicitly specify CMAKE_CXX98_STANDARD_COMPILE_OPTION 6bfb2c6175 HELP: Update compile-features documentation with missing compilers Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5857
| * 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.
* | Merge topic 'nag-fortran-include-moddir'Brad King2021-02-231-0/+1
|\ \ | |/ | | | | | | | | | | ec030877a2 NAG: Fix using Fortran modules from their output directory Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5842
| * 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).
* | Merge topic 'intel-fortran-preprocess'Brad King2021-02-192-4/+20
|\ \ | |/ | | | | | | | | | | | | | | c9244f369a IntelLLVM: Make explicit Fortran preprocessing under Ninja more robust 056d4bf528 Merge branch 'backport-intel-fortran-preprocess' af074c266e Intel: Make explicit Fortran preprocessing under Ninja more robust Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5826
| * 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
* | | Merge topic 'cuda_cleanup'Brad King2021-02-161-2/+2
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | af38d5a1d4 Platform/Windows-NVIDIA-CUDA: Remove duplicated code 4dc1c9e525 CUDA: Fix spelling __IMPLICT_ -> __IMPLICIT_ 4620cf77f2 Clang: Remove unused CUDA implicit link variables Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5812
| * | Clang: Remove unused CUDA implicit link variablesRaul Tambre2021-02-141-2/+2
| | | | | | | | | | | | We don't use/need implicit links for Clang with CUDA.
* | | 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
generated by cgit v0.12 at 2025-02-09 10:46:24 (GMT)