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.
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
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
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
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
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>
Identify the compilers as `NVHPC` to distinguish it from the older PGI
compilers from which they evolved, and from other `NVIDIA` compilers.
Fixes: #20887
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
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.
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 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
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.
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.
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.
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).
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.
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).
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.
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.
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.
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.
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.
