summaryrefslogtreecommitdiff
path: root/Modules/CMakeCompilerIdDetection.cmake
Commit message (Collapse)AuthorAgeFilesLines
* Tasking: Add support for several compiler toolsetsChristoph Seitz2022-09-141-0/+1
| | | | | | | | | | | | | | Add support for the Tasking compiler toolset: * TriCore Compiler Toolset 6.3 (with TriCore, ARM, MCS, 8051 and PCP architecture compilers) * SmartCode Compiler Toolset 10.1 (with TriCore, ARC, MCS, 8051 architecture compilers) * ARM Compiler 6.0 * MCS Complier 3.3 * 8051 Compiler 7.2 Fixes: #23756
* IBMClang: Add support for IBM Open XL C/C++Aaron Liu2022-01-271-0/+1
| | | | Fixes: #22929
* LCC: Add dedicated support for MCST LCC compilermakise-homura2021-10-151-0/+1
| | | | | | | | | | | | | | | | | | | | | 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.
* HIP: Remove ROMClang compiler id and use Clang directlyBrad King2021-09-161-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit bd844387df (ROCMClang: Add the ROCm toolkit derived clang compiler to CMake, 2020-08-28, v3.21.0-rc1~66^2~6) and commit ff0d2858e1 (HIP: Extract clang compiler details from hipcc, 2020-10-21, v3.21.0-rc1~66^2~5), the separate `ROCMClang` compiler id for `hipcc` has caused a few problems: * The compiler id changed from behavior of CMake 3.20 and below, breaking projects that already built with `hipcc` treated as `Clang`. * The implementation of `target_compile_features` was incomplete for the `ROCMClang` identity. * Only `hipcc` was identified as `ROCMClang`, so after it is unwrapped to the underlying `clang++`, future runs of new CMake versions on an existing build tree would not repeat this. * Clang should be usable as a HIP compiler without the `hipcc` wrapper. Remove the `ROMClang` compiler identity, and revise HIP language support to work directly with a Clang compiler. Reject direct `hipcc` usage as a HIP compiler. For now it cannot be supported because it interferes with flags CMake needs to pass to Clang. Fixes: #22536, #22460, #22593
* CompilerId: Tolerate variables named for languagesPhilippe Canal2021-06-181-6/+6
| | | | | | | | | | | | | | | If a project or user sets a variable or cache entry named `C`, `CXX`, `CUDA`, `Fortran`, `CSharp`, or `ISPC`, we were previously comparing each enabled language name to the value of that variable, rather than the name itself. Double-quote the string to take advantage of policy `CMP0054`, but also add "x" prefixes to support projects that do not set the policy. This extends a similar fix in commit bd16a985fc (CompilerId/Features: Tolerate variables named for languages, 2021-04-28) in more places. In particular, ensure that we consider the proper list of compiler ids. Issue: #22125
* ROCMClang: Add the ROCm toolkit derived clang compiler to CMakeRobert Maynard2021-06-071-0/+5
|
* CompilerId/Features: Tolerate variables named for languagesBrad King2021-05-031-1/+1
| | | | | | | | | | | If a `CMakeLists.txt` or `CMAKE_TOOLCHAIN_FILE` sets a variable named `C`, `CXX`, or `CUDA`, we were previously comparing each enabled language name to the value of that variable, rather than the name itself. Double-quote the string to take advantage of policy `CMP0054`, but also add "x" prefixes to support projects that do not set the policy. Fixes: #22125
* FujitsuClang: Add support for the Fujitsu compiler in Clang modeChuck Atkins2021-03-311-0/+1
| | | | | | 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.
* IntelLLVM: Add support for Intel LLVM-based compilersWilliam R. Dieter2021-01-281-0/+1
| | | | | | | | | | | | | | | | | | 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-271-0/+1
| | | | | | | Identify the compilers as `NVHPC` to distinguish it from the older PGI compilers from which they evolved, and from other `NVIDIA` compilers. Fixes: #20887
* Revert "Intel: Add Intel DPC++ compiler identification"Brad King2020-12-071-1/+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-1/+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
* Intel: Add Intel Clang compiler identificationHarini Chilamantula2020-09-291-0/+1
| | | | | The compiler identifies itself with the `__INTEL_CLANG_COMPILER` preprocessor definition.
* Intel: Add Intel DPC++ compiler identificationHarini Chilamantula2020-09-221-0/+1
| | | | | The compiler identifies itself with the `__INTEL_DPCPP_COMPILER__` preprocessor definition.
* Add ISPC compiler support to CMakeRobert Maynard2020-08-281-1/+2
|
* CUDA: Add support for Clang compilerRaul Tambre2020-05-151-2/+1
| | | | | | | | | | | | | | | | | | | When crosscompiling we pass the sysroot. We need to try various architecture flags. Clang doesn't automatically select one that works. First try the ones that are more likely to work for modern installations: * <=sm_50 is deprecated since CUDA 10.2, try sm_52 first for future compatibility. * <=sm_20 is removed since CUDA 9.0, try sm_30. Otherwise fallback to Clang's current default. Currently that's `sm_20`, the lowest it supports. Separable compilation isn't supported yet. Fixes: #16586
* ARMClang: Add support for Clang-based ARM compilerJohan Stridkvist2019-05-141-0/+1
| | | | Fixes: #18215
* Merge topic 'armcc-compiler-id'Brad King2019-03-211-1/+1
|\ | | | | | | | | | | | | 8f8d056051 ARMCC: Fix identification of ARM compiler when it defines GNU macros Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !3127
| * ARMCC: Fix identification of ARM compiler when it defines GNU macrosBrad King2019-03-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | According to ARMCC 5.06 documentation: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0472m/chr1359125007083.html the compiler may define `__GNUC__` in addition to `__ARMCC_VERSION`. Re-order our preprocessor checks to consider the ARM-specific macro first so that the ARM compiler is not mistaken for a GNU compiler. Fixes: #19065
* | Merge topic 'drop-MIPSpro'Brad King2019-03-011-0/+2
|\ \ | | | | | | | | | | | | | | | | | | e21bae378d WCDH: Restore definition for <prefix>_COMPILER_IS_MIPSpro Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !3043
| * | WCDH: Restore definition for <prefix>_COMPILER_IS_MIPSproBrad King2019-02-281-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Code removed for MIPSpro by commit 214fcefa52 (Remove now-unused code once used for MIPSpro on IRIX, 2019-02-21) actually changed a public-facing API by dropping the `<prefix>_COMPILER_IS_MIPSpro` definition from the generated compiler detection header. Restore the definition hard-coded to `0` since the compiler will never be MIPSpro. Reported-by: Hans Johnson <hans-johnson@uiowa.edu>
* | | XLClang: Add a new compiler ID for the clang-based XL compilerChuck Atkins2019-02-251-0/+1
|/ /
* | Remove now-unused code once used for MIPSpro on IRIXBrad King2019-02-211-2/+0
|/ | | | | | 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.
* GHS: Add Compiler ID detectionFred Baksik2019-01-161-0/+1
| | | | | | | | | | | | -- Detect GHS compiler and version Detect ARCHITECTURE_ID for PPC / ARM / 86 targets Detect PLATFORM_ID for Integrity and Integrity178 platforms Using defines specified in the documents for the compilers: 201416 PPC / 201754 ARM / 201714 86 -- Fallback C/CXX compiler ID to GHS if not otherwise detected and using GHS MULTI generator Works around issue with some GHS compilers not setting __ghs__ compiler define -- Tweak Compiler ID checking so major id of 002017 is not replaced with 217 -- Prefer try_compile() library targets when testing for working GHS compilers -- Avoid CMake errors if reading past end of file for checking if file is PE executable
* Remove now-unused code once used on IRIXBrad King2019-01-111-3/+0
| | | | | We dropped support for IRIX as a host platform long ago. Remove some leftover code.
* Use string(APPEND) in ModulesDaniel Pfeifer2017-05-171-4/+4
| | | | | | | Automate with: find Modules -type f -print0 | xargs -0 perl -i -0pe \ 's/set\(([a-zA-Z0-9_\$\{\}]+)(\s+)"\$\{\1\}([^"])/string(APPEND \1\2"\3/g'
* Don't include CMakeParseArgumentsDaniel Pfeifer2017-01-111-2/+0
| | | | | | | | | | | | The cmake_parse_arguments command is builtin with version 3.5. The CMakeParseArguments module is empty and exists for backwards compatibility with CMake 3.4 and lower. Remove the includes of CMakeParseArguments from CMake's modules. The modules are always used with the current version of CMake. Leave the includes in the tests, as the tests may be run with an older version of CMake.
* C# support: add compiler detection for MSVCMichael Stürmer2016-12-151-1/+1
|
* CUDA: We now properly perform CUDA compiler identification.Robert Maynard2016-11-141-0/+5
|
* Simplify CMake per-source license noticesBrad King2016-09-271-12/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Per-source copyright/license notice headers that spell out copyright holder names and years are hard to maintain and often out-of-date or plain wrong. Precise contributor information is already maintained automatically by the version control tool. Ultimately it is the receiver of a file who is responsible for determining its licensing status, and per-source notices are merely a convenience. Therefore it is simpler and more accurate for each source to have a generic notice of the license name and references to more detailed information on copyright holders and full license terms. Our `Copyright.txt` file now contains a list of Contributors whose names appeared source-level copyright notices. It also references version control history for more precise information. Therefore we no longer need to spell out the list of Contributors in each source file notice. Replace CMake per-source copyright/license notice headers with a short description of the license and links to `Copyright.txt` and online information available from "https://cmake.org/licensing". The online URL also handles cases of modules being copied out of our source into other projects, so we can drop our notices about replacing links with full license text. Run the `Utilities/Scripts/filter-notices.bash` script to perform the majority of the replacements mechanically. Manually fix up shebang lines and trailing newlines in a few files. Manually update the notices in a few files that the script does not handle.
* Use string(APPEND) in ModulesDaniel Pfeifer2016-07-281-4/+4
| | | | | | | Automate with: find Modules -type f -print0 | xargs -0 perl -i -0pe \ 's/set\(([a-zA-Z0-9_]+)(\s+)"\$\{\1\}([^"])/string(APPEND \1\2"\3/g'
* Add support for Bruce C Compiler (BCC)Paweł Stankowski2016-03-211-0/+1
| | | | Revise C compiler detection code to be K&R compatible.
* Add support for the ARM Compiler (arm.com)Joakim Andersson2015-11-021-0/+1
| | | | | | | | Create an `ARMCC` compiler id corresponding to compilers identified and versioned by the `__ARMCC_VERSION` predefined macro. See documentation for the compilers at http://infocenter.arm.com/help/topic/com.arm.doc.set.swdev/index.html
* Add Fujitsu compiler detectionErik Lindahl2014-08-111-0/+1
| | | | | | The Fujitsu C/C++ compilers are the default ones for K computer. Detect both native and cross compilers by looking for the __FUJITSU preprocessor definition.
* Project: Detect other compilers before detecting Clang.Stephen Kelly2014-06-131-2/+2
| | | | | | | | | | | | Commit v2.8.10.1~5^2 (Fix PathScale compiler id for Clang-based upstream, 2012-11-05) re-ordered the detection logic for PathScale. Other compiler vendors are also producing Clang-based frontends, so detect "actual" Clang as one of the last compilers to allow for others doing the same. http://llvm.org/devmtg/2014-04/PDFs/Posters/ClangIntel.pdf http://docwiki.embarcadero.com/RADStudio/XE5/en/Clang-based_C%2B%2B_Compilers
* Project: Add configurable name for version computation macros.Stephen Kelly2014-06-051-0/+2
|
* Project: Separate simulated compiler id from version detection.Stephen Kelly2014-06-051-1/+4
|
* Project: Refactor C compiler determination into multiple files.Stephen Kelly2014-05-071-9/+32
|
* CompilerId: Allow specifying a prefix for preprocessor defines.Stephen Kelly2014-05-071-8/+11
|
* CompilerId: Guard the platform-default compiler code with a parameter.Stephen Kelly2014-05-071-6/+6
|
* CompilerId: Add option to generate compiler-id-specific defines.Stephen Kelly2014-05-071-2/+12
|
* CompilerId: Allow specifying the compiler-specific components to generate.Stephen Kelly2014-05-071-2/+18
|
* Project: Split the compiler id detection into a separate function.Stephen Kelly2014-05-071-0/+99
This can be extended with parameters to control the output and re-used in other contexts.
View Lorry Controller Status