summaryrefslogtreecommitdiffstats
path: root/Modules/CMakeFortranCompilerId.F.in
Commit message (Collapse)AuthorAgeFilesLines
* LLVMFlang: Update MSVC ABI and architecture detection for LLVMFlang 18.0Brad King2023-12-061-1/+1
| | | | | | | | LLVMFlang 18.0 adds MSVC ABI and architecture macros. Resolve the corresponding FIXME left by commit 26bf32cdc6 (LLVMFlang: Add support for targeting MSVC ABI on Windows, 2023-09-28, v3.28.0-rc1~10^2). Issue: #24840
* LLVMFlang: Add support for LLVM FlangTin Huynh2022-05-241-0/+7
| | | | | | | | | LLVM Flang (https://github.com/llvm/llvm-project/tree/main/flang) is an LLVM Fortran compiler that shares the same name as Flang (also known as Classic Flang). Classic Flang is in active development and is already identified by CMake as Flang. As such, LLVM Flang will be identified as `LLVMFlang`. Fixes: #22387
* LCC: Add dedicated support for MCST LCC compilermakise-homura2021-10-151-0/+7
| | | | | | | | | | | | | | | | | | | | | 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.
* Modules: Fix typos and spelling in comments of generated codeJosef Angstenberger2021-05-071-1/+1
|
* Merge topic 'intel-2021'Brad King2021-04-291-5/+22
|\ | | | | | | | | | | | | | | 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
| * IntelLLVM: Add special case for ifx 2021.1 version extractionBrad King2021-04-281-0/+8
| | | | | | | | | | | | | | The ifx beta versions forgot to define `__INTEL_LLVM_COMPILER`, and instead define `__INTEL_COMPILER == 201900`. Add a special case. Issue: #22120
| * Intel: Update Classic compiler version detection for 2021Brad King2021-04-281-5/+14
| | | | | | | | | | | | | | The value of the `__INTEL_COMPILER` macro changed convention starting in version 2021. Fixes: #22120
* | Merge topic 'fujitsu-compiler-4.0-support'Brad King2021-04-011-0/+9
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | 8ef55dec29 Help: Add release notes for Fujitsu compiler support 4c74c86f40 FindBLAS/LAPACK: Add support for the Fujitsu SSL2 library 376c300b25 FindOpenMP: Add support for Fujitsu compilers 9e0a1cf03e FindMPI: Add support for the Fujitsu compiler wrappers a237450948 Tests: Update for the FujitsuClang compiler 27579e9cf1 FujitsuClang: Add support for the Fujitsu compiler in Clang mode a55feff69c Tests: Update for the Fujitsu compiler 3c867cff4a Fujitsu: Add support for the Fujitsu compiler in Trad mode Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: Axel Huebl <axel.huebl@plasma.ninja> Acked-by: Gilles Gouaillardet <gilles@rist.or.jp> Merge-request: !5954
| * Fujitsu: Add support for the Fujitsu compiler in Trad modeChuck Atkins2021-03-301-0/+9
| | | | | | | | Co-Author: Yuichiro Utsumi <utsumi.yuichiro@jp.fujitsu.com>
| * Merge topic 'cray-compiler-wrapper-detection'Brad King2021-03-111-1/+1
| |\ | | | | | | | | | | | | | | | | | | 13144e82cd Cray: Enable Cray compiler wrapper detection on all platforms Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5897
| * \ Merge topic 'CrayPrgEnv-detection'Brad King2021-03-091-1/+1
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | 23b101de60 Revert "Cray: Fix Cray compiler detection on new platforms" Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5889
* | | | Cray: Detect Fortran compiler version patch level if availableJustin LaPolla2021-03-311-0/+3
| | | | | | | | | | | | | | | | Fixes: #21969
* | | | Merge topic 'cray-compiler-wrapper-detection' into release-3.20Brad King2021-03-111-1/+1
|\ \ \ \ | | |_|/ | |/| | | | | | | | | | | | | | | | | | 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-1/+1
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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' into release-3.20Brad King2021-03-091-1/+1
|\ \ \ | |/ / | | / | |/ |/| | | | | 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-1/+1
| | | | | | | | | | | | | | | | | | | | 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
* | IntelLLVM: Add support for Intel LLVM-based compilersWilliam R. Dieter2021-01-281-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+17
|/ | | | | | | Identify the compilers as `NVHPC` to distinguish it from the older PGI compilers from which they evolved, and from other `NVIDIA` compilers. Fixes: #20887
* Cray: Fix Cray compiler detection on new platformsJustin LaPolla2020-12-011-1/+1
| | | | | | | | | | | | | | | | 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
* Remove now-unused code once used for MIPSpro on IRIXBrad King2019-02-211-7/+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.
* Remove now-unused code once used on IRIXBrad King2019-01-111-14/+2
| | | | | We dropped support for IRIX as a host platform long ago. Remove some leftover code.
* Flang: Identify as simulating MSVC on WindowsIsuru Fernando2017-10-311-21/+20
| | | | | | In `CMakeFortranCompilerId.F.in`, take the `_MSC_VER` out of the Intel-specific block so it will trigger for other compilers like Flang. In `Compiler/Clang.cmake`, switch off Fortran too.
* Flang: Add support for flang Fortran compilerTin Huynh2017-08-311-0/+7
| | | | | | | | | | | | | | flang is a Fortran compiler built on top of clang [1]. Because flang shares a lot of commonalities with clang, the flang module piggybacks off the clang module and overrides certain options. Add flang to Fortran compiler auto find list. Update flang preprocessor macros to differentiate from PGI. Add Flang-FindBinUtils. [1] https://github.com/flang-compiler/flang
* NAG: Detect compiler version of NAG FortranTom Clune2017-05-051-0/+5
| | | | Fixes: #16817
* Cray: Add macro tests to detect the Cray compiler wrappersChuck Atkins2015-12-071-0/+3
|
* Merge topic 'cray-fortran-version'Brad King2015-11-131-0/+2
|\ | | | | | | | | 09f754f0 Cray: Implement Fortran compiler version detection (#15845)
| * Cray: Implement Fortran compiler version detection (#15845)Brad King2015-11-121-0/+2
| | | | | | | | | | | | We already recognize the Cray Fortran compiler id. Extract the version number using the same predefined macros we already use for Cray C and C++ compilers.
* | Intel: Recognize MSVC version for Intel Fortran 2016 (#15809)Brad King2015-10-261-1/+3
|/
* Fortran: Detect G95 compiler versionBrad King2015-02-191-0/+2
| | | | | The __G95__ and __G95_MINOR__ preprocessor symbols encode the compiler version as decimal digits.
* Fortran: Detect PGI compiler versionBrad King2015-02-191-0/+5
| | | | | Port logic from the "Compiler/PGI-DetermineCompiler" module into "CMakeFortranCompilerId.F.in".
* Fortran: Detect XL and VisualAge compiler versionsBrad King2015-02-191-0/+6
| | | | | | Port logic from the "Compiler/XL-*-DetermineCompiler" and "Compiler/VisualAge-*-DetermineCompiler" modules into "CMakeFortranCompilerId.F.in".
* Fortran: Detect GNU compiler versionBrad King2015-02-191-0/+5
| | | | | Port logic from the "Compiler/GNU-DetermineCompiler" module into "CMakeFortranCompilerId.F.in".
* Fortran: Detect PathScale compiler versionBrad King2015-02-191-0/+5
| | | | | Port logic from the "Compiler/PathScale-DetermineCompiler" module into "CMakeFortranCompilerId.F.in".
* Fortran: Detect SunPro compiler versionBrad King2015-02-191-1/+9
| | | | | Port logic from "Compiler/SunPro-*DetermineCompiler" modules into "CMakeFortranCompilerId.F.in".
* Fortran: Detect Intel compiler versionBrad King2015-02-191-0/+11
| | | | | Port logic from the "Compiler/Intel-DetermineCompiler" module into "CMakeFortranCompilerId.F.in".
* Fortran: Add infrastructure to detect compiler version (#15372)Brad King2015-02-191-0/+22
| | | | | | | | Fortran does not offer syntax to compose a string literal at preprocessing time from numeric compuations. Instead encode each digit of each component as a separate INFO string and compose them in CMake code after extraction. Support MAJOR, MINOR, PATCH, and TWEAK components with up to 8 digits each.
* Intel: Fix detection of MSVC version simulated by pre-11.0 FortranBrad King2013-10-181-3/+1
| | | | | | | The Intel Fortran 10 64-bit compiler incorrectly defines _MSC_VER to its own version (1020) instead of the underlying MSVC tools version. Since we expect the compiler to be used only with VS >= 7 tools, assume MSVC version 13.0 if _MSC_VER is not greater than 1300.
* Intel: When simulating MSVC, re-use Windows-MSVC (#14476)Brad King2013-10-181-0/+20
| | | | | | | | | 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).
* check for Haiku only with __HAIKU__Rolf Eike Beer2013-01-071-5/+1
|
* Add Absoft Fortran compiler id and basic flagsBrad King2011-05-201-0/+2
| | | | | Identification at preprocessing time depends on definition of __ABSOFT__ to be added in service pack V11.1.2 of the compiler.
* Detect Fortran target architecture on WindowsBrad King2010-12-161-0/+9
| | | | | | | Commit 4430bccc (Change the way 32/64 bit compiles are detected with MSVC and intel, 2009-11-19) added detection of the target processor to C and CXX language builds with MS and Intel tools. Do the same for Intel Fortran for Windows (ifort). Use /machine:<arch> to link executables.
* Teach CMake about Cray C, C++, and Fortran compilersBrad King2010-11-121-0/+2
| | | | | | The Cray Fortran compiler needs "-em" to enable module output and also "-J." to place the .mod files in the current working directory (instead of next to the .o file).
* Recognize the PathScale C/C++/Fortran compilersBrad King2010-01-131-0/+2
|
* Add support for the g95 Fortran compilerBrad King2009-10-231-0/+2
| | | | | | | | | | This commit teaches CMake about the g95 compiler from http://www.g95.org We use 'G95' as the compiler id string, and add some basic flags. See issue #9241.
* Teach compiler id about VisualAge -> XL rebrandingBrad King2009-08-071-1/+7
| | | | | | | IBM rebranded its VisualAge compiler to XL starting at version 8.0. We use the compiler id "XL" for newer versions and "VisualAge" for older versions. We now also recognize the "z/OS" compiler, which is distinct from XL.
* ENH: Check _SGI_COMPILER_VERSION for compiler idBrad King2009-07-141-1/+1
| | | | | | Some SGI compilers define _SGI_COMPILER_VERSION in addition to the old _COMPILER_VERSION preprocessor symbol. It is more distinctive, so we should check it in case the old one is ever removed.
* BUG: Avoid SGI preprocessor bug for Fortran IdBrad King2009-07-141-2/+10
| | | | | | | | | | | | | | | | | The SGI preprocessor /usr/lib/cpp produces bad output on this code: #if 1 A #elif 1 B #else C #endif Both 'A' and 'C' appear in the output! We work around the problem by using '#elif 1' instead of '#else'. This fixes detection of the SGI Fortran compiler id in -o32 mode.
* ENH: Identify Fortran compilers with fixed formatBrad King2009-06-251-0/+92
This enhances the Fortran compiler id detection by using a source that can compile either as free or fixed format. As long as the compiler knows it should preprocess the source file (.F) the identification can work. Even free-format compilers may try fixed-format parsing if the user specifies certain flags, so we must support both.
generated by cgit v0.12 at 2024-12-26 03:24:10 (GMT)