summaryrefslogtreecommitdiffstats
path: root/Modules/CMakeCCompilerId.c.in
Commit message (Collapse)AuthorAgeFilesLines
* CompilerId: Fix default extensions check for Clang targeting MSVC ABIBrad King2022-02-031-2/+1
| | | | | | | | | | | | | In commit fc3a1cbdd8 (CompilerID: Compiler extensions default detection, 2021-05-29, v3.22.0-rc1~52^2~2), extensions were assumed to be `OFF` for Clang targeting the MSVC ABI. However, the `clang` and `clang++` tools both seem to have extensions enabled by default even when targeting the MSVC ABI. This can be observed with the `RunCMake.CompileFeatures` test. It fails with the GNU-like `clang/clang++` front-end, but removing the above special case makes it pass. The test passes either way with the MSVC-like `clang-cl` front-end.
* XL: Detect default extensions mode for legacy compilerRaul Tambre2022-01-231-1/+1
| | | | | The legacy non-Clang variant seems to support a GNU-like extensions mode, which is the default. Enable detection for it.
* CompilerId: Restore support for classic C by avoiding C++ style commentsBrad King2021-11-231-1/+1
| | | | | | | | | C++ style comments were added by commit fc3a1cbdd8 (CompilerID: Compiler extensions default detection, 2021-05-29, v3.22.0-rc1~52^2~2), but they may not be supported by the default mode of some C compilers. Use C-style comments instead. For consistency, do this for all languages. Fixes: #22942
* CompilerID: Compiler extensions default detectionRaul Tambre2021-09-281-0/+12
|
* CompilerID: Rename language_dialect to language_standardRaul Tambre2021-09-281-10/+10
| | | | | In Linux C++ terms dialect usually refers to having GNU extensions or not. Change the name to better reflect that this is about the standard version.
* Compilers: protect use of __has_includeZack Galbreath2021-06-071-0/+6
| | | | If the compiler does not have __has_include, pretend the answer is always no
* Merge topic 'cray-compiler-wrapper-detection'Brad King2021-03-111-2/+2
|\ | | | | | | | | | | | | 13144e82cd Cray: Enable Cray compiler wrapper detection on all platforms Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5897
| * Cray: Enable Cray compiler wrapper detection on all platformsJustin LaPolla2021-03-101-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously were checking for the `__CRAYXC` and `__CRAYXE` predefined macros. These macros reflect the platform that the compiler wrapper is running on, i.e. Cray XC and Cray XE machines. They are not defined on other platforms such as Apollo80. Switch to the `__CRAYXT_COMPUTE_LINUX_TARGET` macro. The Cray cc/CC/ftn wrappers always define this macro on the command line. This macro has been in use for many years, and is believed to be a reliable way to detect current and older Cray compiler wrappers. Fixes: #21904
* | Merge topic 'CrayPrgEnv-detection'Brad King2021-03-091-2/+2
|\ \ | |/ | | | | | | | | | | 23b101de60 Revert "Cray: Fix Cray compiler detection on new platforms" Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5889
| * Revert "Cray: Fix Cray compiler detection on new platforms"Brad King2021-03-081-2/+2
| | | | | | | | | | | | | | | | | | | | The justification in commit 9ee4a42813 (Cray: Fix Cray compiler detection on new platforms, 2020-12-01, v3.19.2~26^2) confuses detection of the CrayPrgEnv with identification of the Cray compiler. The change regressed detection of the CrayPrgEnv on non-Cray compilers. Revert it pending further investigation into the original problem. Fixes: #21894
* | C23 supportRaul Tambre2021-02-251-0/+2
| |
* | C17 supportRaul Tambre2021-02-251-0/+2
| | | | | | | | Implements #17755.
* | CMakeCCompilerId: Fix C standard detection in Clang MSVC modeRaul Tambre2021-02-251-3/+2
|/ | | | | | Clang doesn't define __STDC__ if in MSVC compatibility mode, but does define __STDC_VERSION__. Avoid the fallback for this combination.
* Cray: Fix Cray compiler detection on new platformsJustin LaPolla2020-12-011-2/+2
| | | | | | | | | | | | | | | | Customer reported problems detecting the Cray compiler on their Apollo80 system. We were checking for the __CRAYXC and __CRAYXE predefined macros. These macros reflect the platform that the compiler is running on, i.e. Cray XC and Cray XE machines. Naturally, this didn't work on Apollo80. This commit uses the official Cray compiler identification macros which are defined on every platform: CCE Version C Macro C++ Macro Fortran Macro ============ ======== ========= ============= version < 9 _CRAYC _CRAYC _CRAYFTN version >= 9 __cray__ __cray__ _CRAYFTN
* XL: Fix C default level detection when invoked as 'cc'Brad King2018-03-141-1/+2
| | | | | | | | | The IBM XL C compiler does not define `__STDC__` when invoked as plain `cc` instead of `xlc`, so `CMAKE_C_STANDARD_COMPUTED_DEFAULT` does not get set and CMake fails. Teach CMake about the XL compiler's default C standard in this case. Fixes: #17649
* Add infrastructure to detect secondary compiler version informationBrad King2017-10-031-0/+3
| | | | | | | | | | | Create a `CMAKE_<LANG>_COMPILER_VERSION_INTERNAL` variable to hold a secondary/internal compiler version number detected at the same time as the primary compiler version. This will be useful for some compilers where we need such a number to determine correct usage. Inspired-by: Stefan Andersson <tfosm@hotmail.com> Suggested-by: Norbert Lange <norbert.lange@andritz.com> Issue: #17264
* Features: Detect C default dialect on MSVC-like compilersBrad King2016-04-281-1/+5
| | | | | | These compilers default to C 90 but do not define __STDC__. While MSVC itself has no option to change the dialect, compilers that document compatibility with MSVC and define _MSC_VER may (e.g. Intel).
* Add support for Bruce C Compiler (BCC)Paweł Stankowski2016-03-211-6/+16
| | | | Revise C compiler detection code to be K&R compatible.
* Cray: Add macro tests to detect the Cray compiler wrappersChuck Atkins2015-12-071-0/+7
|
* Make C and C++ default dialect detection robust to advanced optimizationsBrad King2015-11-181-0/+1
| | | | | | | | | | | In commit v3.4.0-rc1~71^2 (Project: Determine default language dialect for the compiler, 2015-09-15) we added an "INFO:..." string to the compiler id detection binary. The value can be optimized out of the compiler id binary unless we force it to be included by making the program behavior depend on it at runtime. Add references to the value as we do for the other info strings already. Gentoo-Issue: https://bugs.gentoo.org/show_bug.cgi?id=565744
* Project: Determine default language dialect for the compiler.Stephen Kelly2015-09-181-0/+11
| | | | | | Use the __cplusplus and __STDC_VERSION__ macros to automatically determine the default dialect for the compiler while determining its id and version.
* QNX: Fix detection of QCC compiler id (#15349)Brad King2015-01-141-1/+1
| | | | | | | In commit v3.1.0-rc1~113^2 (Use a more reliable regex for extracting binary INFO strings, 2014-09-03) the matching of INFO: strings was made more strict and no longer matches just "INFO:qnxnto". Use "INFO:qnxnto[]" instead to conform to the new pattern.
* Project: Refactor C compiler determination into multiple files.Stephen Kelly2014-05-071-224/+1
|
* Project: Clarify comment about platform-native compilers.Stephen Kelly2014-05-071-1/+1
|
* Watcom: Introduce OpenWatcom compiler id and fix compiler versionJiri Malak2014-03-171-4/+13
| | | | | | Distinguish "Open Watcom" from old "Watcom" by introducing a new "OpenWatcom" compiler id. The __WATCOMC__ format is "VVRP" for Watcom and "VVRP + 1100" for Open Watcom.
* CMake*CompilerId: Fix patch level for Intel >= 14.0 (#14806)Brad King2014-03-141-1/+5
| | | | | | | | | | | | According to the Intel release notes: http://software.intel.com/sites/default/files/l-compiler-release-update.pdf the __INTEL_COMPILER_UPDATE predefined macro was introduced to hold the third version component. Reported-by: Dirk Ribbrock <dirk.ribbrock@mathematik.uni-dortmund.de> Co-Author: Rolf Eike Beer <kde@opensource.sf-tec.de>
* QNX: Introduce QCC compiler id for that QNX platform compiler.Stephen Kelly2014-01-221-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | Introduce policy CMP0047 to control resetting the id for compatibility. De-duplicate content in the QNX platform file by including the GNU one. QNX is a form of GNU platform. Do not clear CMAKE_SHARED_LIBRARY_${lang}_FLAGS variables. They are populated again later by the Compiler/GNU.cmake file anyway. Modify the CMAKE_CXX_COMPILE_OBJECT variable only when the QCC compiler id is in use, and the language is CXX. Use the QNX recommended flag for QCC instead of the gcc compatible -x flag. Populate new module files to handle system includes and depfiles when using the QCC compiler. Remove code which unsets the system include and depfiles related variables. When a GNU driver is used instead of the QCC one, the appropriate flags will be used. These variables were previously cleared for lowest-common-denominator compatibility with both drivers.
* Require CMAKE_<LANG>_COMPILER to be found as a full pathBrad King2013-10-281-0/+1
| | | | | | | | | | | | | | | | | | | | All generators now support detection of the full path to the compiler, so require it to be so. This will allow CMake<LANG>Information.cmake and other logic to assume the full path to the compiler tool is available. The Makefile generators already rejected CMAKE_<LANG>_COMPILER values that did not name an existing compiler. Extend this error message to all generators, make it occur as early as possible, and improve the message with advice about how to set the compiler. If the full path to the compiler is not known, finish enabling languages with a fatal error so configuration does not continue. For now, allow the RC language compiler to not be a full path. Later we will need to detect the full path to "rc" under the VS IDE. Add a RunCMake.CompilerNotFound test to cover failure cases. Fix the RunCMake.CompilerChange test EmptyCompiler case to work when configuration does not continue past enable_language.
* Intel: When simulating MSVC, re-use Windows-MSVC (#14476)Brad King2013-10-181-0/+6
| | | | | | | | | Teach CMake(C|CXX|Fortran)CompilerId* to report the MSVC version simulated by the Intel compiler, if any. Refactor the Windows-Intel platform information helper module to load Windows-MSVC instead of duplicating the information. Teach Windows-MSVC to understand when it is loaded as the simulated Fortran compiler (its preprocessor is simulated).
* Merge topic 'apple-clang-id'Brad King2013-10-091-1/+6
|\ | | | | | | | | | | | | 1763c31 Set policy CMP0025 to NEW while building CMake itself aa53ee5 Add policy CMP0025 for Apple Clang compiler id compatibility ab65862 Clang: Add separate "AppleClang" compiler id
| * Clang: Add separate "AppleClang" compiler idBrad King2013-10-081-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | Apple distributes their own Clang build with their own version numbers that differ from upstream Clang. Use the __apple_build_version__ symbol to identify the Apple Clang compiler and report the Apple Build Version as the fourth version component in CMAKE_<LANG>_COMPILER_VERSION. Add Compiler/AppleClang-<lang> and Platform/Darwin-AppleClang-<lang> modules that simply include the upstream equivalents. Fix comparisons of CMAKE_<LANG>_COMPILER_ID to Clang in CMake's own source and tests to account for AppleClang.
* | Clang: Support Windows variants for GNU and MSVC (#13035, #14458)Brad King2013-10-041-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Teach the compiler identification preprocessor tests to report when Clang simulates MSVC, and what version. If not MSVC, assume GNU. Teach compiler information modules Clang-(C|CXX) to recognize when Clang simulates MSVC and skip loading the GNU information. Teach the Windows-MSVC platform information to recognize when it is loaded as the simulated compiler and use that version information instead of the real compiler's (different) version scheme. Add platform modules Windows-Clang-(C|CXX) and support module Windows-Clang to load either Windows-MSVC or Windows-GNU and wrap the corresponding information macros.
* | CMakeDetermineCompilerId: Add notion of "simulated" id/versionBrad King2013-10-041-0/+9
|/ | | | | | | | | Some compilers try to simulate other compilers as a drop-in replacement supporting all the same command-line options and predefined preprocessor macros. In such cases it will be useful to have CMake load the compiler information files for the simulated compiler instead of duplicating the information. Teach CMakeDetermineCompilerId to extract the simulated compiler id and version when the compiler id detection provides it.
* Add IAR to the CMakeDetectC(XX)CompilerID.c(pp).inAlex Neundorf2013-04-151-4/+3
| | | | | | | With the AVR IAR compiler this can't be found, but it works e.g. for the ARM AVR compiler. Alex
* rename TI_DSP toolchain to TI, since it works also for the ARM compilerAlex Neundorf2013-03-141-1/+1
| | | | | | Additionally, look for a special ar and strip Alex
* VS: Add the entry point when compiling for WindowsCEPatrick Gansterer2012-11-301-4/+0
| | | | | Set the entry point to mainACRTStartup to make sure that main() can be found when linking the application to check the compiler.
* VS: Make DetermineCompilerId working with WinCE tooPatrick Gansterer2012-11-271-0/+4
| | | | | | Add a dummy mainCRTStartup() function, since the linker searches for it instead of main() and set the CMAKE_SYSTEM_* variables depending on the MSVC_C_ARCHITECTURE_ID and CMAKE_VS_WINCE_VERSION variables.
* Fix PathScale compiler id for Clang-based upstreamBrad King2012-11-051-8/+8
| | | | | | | Upstream PathScale now uses Clang as its front-end. Test for __PATHCC__ before __clang__. Reported-by: C. Bergström <cbergstrom@pathscale.com>
* Detect Analog VisualDSP++ compiler version with its idBrad King2012-08-221-2/+9
| | | | | | | | | | | | Decode hex digits from __VISUALDSPVERSION__ to compute the version number components. Note that the constant encodes decimal digits as hex digits (never larger than 9). We represent them as decimal after extraction. See documentation at: http://download.analog.com/dsp/tools/VisualDSP_45_Update_6_Release_Note_v4.pdf http://www.analog.com/static/imported-files/software_manuals/50_asm_man.rev3.1.pdf Note that __VISUALDSPVERSION__ was introduced in version 4.5.6.
* Detect Cray compiler version with its idBrad King2012-08-221-0/+2
| | | | | | | | | | | | Decode decimal digits from _RELEASE _RELEASE_MINOR to compute version number components. See documentation at: http://docs.cray.com/books/S-2179-52/html-S-2179-52/zfixed5fvzxnxo.html http://sourceforge.net/p/predef/wiki/Compilers/#cray-c
* Detect SDCC compiler version with its idBrad King2012-08-221-0/+4
| | | | | | | | Decode decimal digits from SDCC to compute version number components. See documentation at: http://sdcc.sourceforge.net/doc/sdccman.pdf http://sourceforge.net/p/predef/wiki/Compilers/#small-device-c-compilerhttpenwikipediaorgwikismall_device_c_compiler
* Detect TI compiler version with its idBrad King2012-08-221-0/+4
| | | | | | | | | Decode decimal digits from __TI_COMPILER_VERSION__ to compute version number components. See documentation at: http://processors.wiki.ti.com/index.php/Refer_to_Compiler_Version_in_Your_Source http://www.ti.com/general/docs/lit/getliterature.tsp?literatureNumber=spru187o http://sourceforge.net/p/predef/wiki/Compilers/#texas-instruments-cc-compiler
* Detect PathScale compiler version with its idBrad King2012-08-221-1/+6
| | | | | | | | | | | | | Decode decimal digits from __PATHCC__ __PATHCC_MINOR__ __PATHCC_PATCHLEVEL__ to compute version number components. See documentation at: http://www.pathscale.com/docs/UserGuide.pdf http://sourceforge.net/p/predef/wiki/Compilers/#ekopathhttpenwikipediaorgwikipathscale
* Detect Compaq compiler version with its idBrad King2012-08-221-0/+4
| | | | | | | | | Decode decimal digits from __DECC_VER and __DECCXX_VER to compute version number components. See documentation at: http://www.openvms.compaq.com/commercial/c/docs/5492p024.html#decc_ver_sec http://www.tru64unix.compaq.com/cplus/ugu_impl.html#predef_vernum http://sourceforge.net/p/predef/wiki/Compilers/#compaq-cchttpwwwopenvmscompaqcomopenvmsbrochuresdeccplus
* Recognize Embarcadero compiler (#12604)Brad King2012-02-201-0/+6
| | | | | | | | | | | | | | | | | | | The Borland compiler was re-branded as CodeGear during 2007-2009 and since 2009 is the Embarcadero compiler. They offer predefined macros: http://docwiki.embarcadero.com/RADStudio/en/Predefined_Macros and distinguish themselves by __CODEGEARC__ and __CODEGEARC_VERSION__. Version 6.30 (C++Builder XE) changed the meaning of some flags: http://docwiki.embarcadero.com/RADStudio/en/C%2B%2B_Compiler_Option_Changes_for_XE Teach Embarcadero compiler information files to generate build rules with flags matching the compiler version. Leave the flags unchanged for old Borland versions. Always set the BORLAND toolchain indicator for compatibility with existing projects that test it. Also set the EMBARCADERO indicator for newer toolchains.
* Merge topic 'compiler-version'David Cole2012-01-171-3/+83
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 0df1942 Detect SGI MIPSpro compiler version with its id a5e892c Document compiler version macro formats used for detection d7c6f41 Detect HP compiler version with its id 3dd9fa9 Detect SunPro compiler version with its id c198730 Detect Watcom compiler version with its id 5899b98 Detect Clang compiler version with its id b8cfa65 Detect PGI compiler version with its id 6dae666 Detect IBM XL compiler version with its id 4080d55 Detect Borland compiler version with its id 2cc205a Detect Intel compiler version with its id (#11937) a6d83cc Detect MSVC compiler version with its id a662855 Detect GNU compiler version with its id (#6251) fa7141f Add framework to detect compiler version with its id (#12408)
| * Detect SGI MIPSpro compiler version with its idBrad King2012-01-101-0/+11
| | | | | | | | | | | | | | Decode decimal digits from _SGI_COMPILER_VERSION or _COMPILER_VERSION to compute version number components. See documentation at: http://predef.sourceforge.net/precomp.html
| * Document compiler version macro formats used for detectionBrad King2012-01-101-0/+14
| | | | | | | | | | | | The MSVC, HP, XL, SunPro, Watcom, Borland, and Intel compilers specify their version number in components encoded in a single integer value. Document the components that we use to compute version numbers.
| * Detect HP compiler version with its idBrad King2012-01-101-0/+3
| | | | | | | | | | | | | | | | Decode decimal digits from __HP_cc and __HP_aCC to compute version number components. See documentation at: http://predef.sourceforge.net/precomp.html http://g4u0420c.houston.hp.com/en/14487/preprocess.htm
| * Detect SunPro compiler version with its idBrad King2012-01-101-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Decode hex digits from __SUNPRO_C and __SUNPRO_CC to compute the version number components. Note that the constant encodes decimal digits as hex digits (never larger than 9). We represent them as decimal after extraction. See documentation at http://predef.sourceforge.net/precomp.html Although the documented version number format is 0xVRP where V = Version, R = Revision, P = Patch it holds only though SunPro C/C++ version 5.9. Later versions have a two-digit revision (minor) number so their format is 0xVRRP.
generated by cgit v0.12 at 2024-11-11 11:11:02 (GMT)