CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2022-10-11T10:44:08-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/24047Intel Fortran: compiler option "/QSave" not converted to project property wit...2022-10-11T10:44:08-04:00Maarten BraakhekkeIntel Fortran: compiler option "/QSave" not converted to project property with MS Visual StudioIt seems that compiler option `/Qsave` is not recognized as such by CMake and thus not converted to the corresponding project property ("Fortran>Data>Local Variable Storage") in MS Visual Studio with Intel OneAPI.
I would expect that ad...It seems that compiler option `/Qsave` is not recognized as such by CMake and thus not converted to the corresponding project property ("Fortran>Data>Local Variable Storage") in MS Visual Studio with Intel OneAPI.
I would expect that adding compiler option `/Qsave` (e.g. `target_compile_options(tmp PRIVATE /Qsave)`), would result in property "Local Variable Storage" being set to value "All Variables SAVE (/Qsave)". This is not the case, as shown below.
![cmake_fortran_qsave_pic1](/uploads/0d9d4a09a8ef17b7a2d6e5958f18dc42/cmake_fortran_qsave_pic1.png)
Instead it's added as "Additional Option".
![cmake_fortran_qsave_pic2](/uploads/a22901fe65187afb6debc1d1ef9095b7/cmake_fortran_qsave_pic2.png)
For compiler option `/traceback` it does work correctly.
![cmake_fortran_qsave_pic3](/uploads/84834e8c5993a3ea760a95d073e80965/cmake_fortran_qsave_pic3.png)
Is this expected behavior?
Minimal example: [tmp.f90](/uploads/f1d06bb6b8dfedc4c8acaeed0f4f0bc3/tmp.f90), [CMakeLists.txt](/uploads/9b0f5e57799bd54b130a1f444ae98377/CMakeLists.txt)
My system:
- Windows 10 x64
- MS Visual Studio Professional x64 17.1.7
- Intel Fortran Compiler 2022.1.0.256
- CMake 3.24.0https://gitlab.kitware.com/cmake/cmake/-/issues/23948Intel on Windows might have spaces in SDK paths2022-09-14T08:14:34-04:00Ben BoeckelIntel on Windows might have spaces in SDK pathsIntel on Windows has logic to disable `deps = gcc` usage when there are spaces in the source paths. However, the "does not properly escape spaces" can still hit if any dependencies have spaces in their paths.
Reported on Discourse: http...Intel on Windows has logic to disable `deps = gcc` usage when there are spaces in the source paths. However, the "does not properly escape spaces" can still hit if any dependencies have spaces in their paths.
Reported on Discourse: https://discourse.cmake.org/t/problems-building-project-command-line-with-intel-compiler-and-ninja-generator/6244
Relevant MR: !5557
/cc @brad.king @marc.chevrierMarc ChevrierMarc Chevrierhttps://gitlab.kitware.com/cmake/cmake/-/issues/22773Intel 2021.4.0: Fortran ABI info detection fails in VS 16.11.52022-01-09T13:57:48-05:00Boris BasicIntel 2021.4.0: Fortran ABI info detection fails in VS 16.11.5Both are last versions of Visual Studio 2019 and Intel oneAPI 2021 respectively. I also tried with Intel Fortran 2021.3.0 but the issue was still there. It can easily be reproduced with the following `CMakeLists.txt`:
```cmake
cmake_min...Both are last versions of Visual Studio 2019 and Intel oneAPI 2021 respectively. I also tried with Intel Fortran 2021.3.0 but the issue was still there. It can easily be reproduced with the following `CMakeLists.txt`:
```cmake
cmake_minimum_required(VERSION 3.21)
project(test-intel-fortran)
enable_language(Fortran)
```
The error is the following:
```
-- The Fortran compiler identification is Intel 2021.4.0.20210910
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - failed
-- Check for working Fortran compiler: C:/Program Files (x86)/Intel/oneAPI/compiler/2021.4.0/windows/bin/intel64/ifort.exe
-- Check for working Fortran compiler: C:/Program Files (x86)/Intel/oneAPI/compiler/2021.4.0/windows/bin/intel64/ifort.exe - broken
CMake Error at C:/Program Files/CMake/share/cmake-3.21/Modules/CMakeTestFortranCompiler.cmake:54 (message):
The Fortran compiler
"C:/Program Files (x86)/Intel/oneAPI/compiler/2021.4.0/windows/bin/intel64/ifort.exe"
is not able to compile a simple test program.
```
The issue has also been raised recently on [Stack Overflow](https://stackoverflow.com/questions/69429393/detecting-fortran-compiler-abi-info-failed) and is still present in 3.22.0-rc1.https://gitlab.kitware.com/cmake/cmake/-/issues/22673InstallRequiredSystemLibraries: Wrong library path for Intel fortran 2021 (on...2022-03-09T12:47:25-05:00Thanh-Chung DinhInstallRequiredSystemLibraries: Wrong library path for Intel fortran 2021 (oneAPI)On Windows in file
"C:\Program Files\CMake\share\cmake-3.21\Modules\InstallRequiredSystemLibraries.cmake"
at Line 83 and 84
```
if(WIN32 AND EXISTS "${_Intel_basedir}/../redist/${_Intel_archdir}_win/compiler")
get_filename...On Windows in file
"C:\Program Files\CMake\share\cmake-3.21\Modules\InstallRequiredSystemLibraries.cmake"
at Line 83 and 84
```
if(WIN32 AND EXISTS "${_Intel_basedir}/../redist/${_Intel_archdir}_win/compiler")
get_filename_component(_Intel_redistdir "${_Intel_basedir}/../redist/${_Intel_archdir}_win/compiler" ABSOLUTE)
```
should be
```
if(WIN32 AND EXISTS "${_Intel_basedir}/../../redist/${_Intel_archdir}_win/compiler")
get_filename_component(_Intel_redistdir "${_Intel_basedir}/../../redist/${_Intel_archdir}_win/compiler" ABSOLUTE)
```
as fas as I can tell from my Intel Fortran installation.3.22.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/22283InstallRequiredSystemLibraries with Intel OneAPI2021-09-23T09:49:08-04:00Jason JonesInstallRequiredSystemLibraries with Intel OneAPIThe InstallRequiredSystemLibraries script in CMake 3.20.3 doesn't take into account the location of the runtime DLLs for Intel's OneAPI Fortran compiler. The script, around lines 77-81, sets either intel64 or ia32 but with OneAPI, the fo...The InstallRequiredSystemLibraries script in CMake 3.20.3 doesn't take into account the location of the runtime DLLs for Intel's OneAPI Fortran compiler. The script, around lines 77-81, sets either intel64 or ia32 but with OneAPI, the folder is intel64_win.3.20.4Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/22165VS: Selecting Intel Fortran compiler version2021-05-07T10:38:43-04:00Xiaofeng WangVS: Selecting Intel Fortran compiler versionIn my setup there are VS2017, Intel Fortran Compiler 2017 and 2019. I would like to use Intel Fortran compilers 2017 based on the below setups:
1. call VsDevCmd.bat from the Visual Studio
2. call %IFORT_COMPILER17%bin\ifortvars.bat
3. se...In my setup there are VS2017, Intel Fortran Compiler 2017 and 2019. I would like to use Intel Fortran compilers 2017 based on the below setups:
1. call VsDevCmd.bat from the Visual Studio
2. call %IFORT_COMPILER17%bin\ifortvars.bat
3. set FC to 2017 ifort.exe
4. call cmake using NMAKE or Visual Studio generator
When running with NMAKE generator it works fine, Intel Fortran compiler 2017 was picked up correctly:
```
cmake -G"NMake Makefiles" -S "D:\source\code" -B "build\NMake Makefiles"
-- The C compiler identification is MSVC 19.12.25835.7
-- The CXX compiler identification is MSVC 19.12.25835.7
-- The Fortran compiler identification is Intel 17.0.6.20171215
```
But with Visual Studio generator CMake picks up Intel Compiler 2019:
```
cmake -G"Visual Studio 15 2017" -A"x64" -T"host=x64,version=14.12" -S "D:\source\code" -B "build\Visual Studio 15 2017"
-- The C compiler identification is MSVC 19.12.25835.7
-- The CXX compiler identification is MSVC 19.12.25835.7
-- The Fortran compiler identification is Intel 19.1.3.20201010
```
As we know when installing Parallel Studio for the Fortran compiler, the Parallel Studio installer does some integration with Visual Studio, could that integration somehow cause the issue?https://gitlab.kitware.com/cmake/cmake/-/issues/22120Intel: Classic Compiler 2021.2.0 20210228 detected as 20.2.2.202102282021-04-30T11:31:49-04:00Martin BlanchardIntel: Classic Compiler 2021.2.0 20210228 detected as 20.2.2.20210228Running CMake 3.20.1 with [latest ICC 2021.2.0 as the oneAPI standalone component](https://software.intel.com/content/www/us/en/develop/articles/oneapi-standalone-components.html#inpage-nav-5-undefined):
```sh
$ icc --version
icc (ICC) ...Running CMake 3.20.1 with [latest ICC 2021.2.0 as the oneAPI standalone component](https://software.intel.com/content/www/us/en/develop/articles/oneapi-standalone-components.html#inpage-nav-5-undefined):
```sh
$ icc --version
icc (ICC) 2021.2.0 20210228
Copyright (C) 1985-2021 Intel Corporation. All rights reserved.
```
```sh
$ cmake -DCMAKE_CXX_COMPILER=icc ...
-- The C compiler identification is Intel 20.2.2.20210228
-- The CXX compiler identification is Intel 20.2.2.20210228
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /home/mblanchard/intel/oneapi/compiler/2021.2.0/linux/bin/intel64/icc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /home/mblanchard/intel/oneapi/compiler/2021.2.0/linux/bin/intel64/icc - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMAKE_CXX_COMPILER_ID=Intel
CMAKE_CXX_COMPILER_VERSION=20.2.2.20210228
CMAKE_CXX_COMPILER_VERSION_MAJOR=20
CMAKE_CXX_COMPILER_VERSION_MINOR=2
```
I wonder how CMake determines that the major version is 20. I'm not an ICC expert - at all - but I haven't been able to find reference to that number in Intel's documentation (I haven't been able to find a release history page in that documentation to be fair, [the best I found is Wikipedia](https://en.wikipedia.org/wiki/Intel_C%2B%2B_Compiler#Release_history)). Intel products version numbering has changed with their new oneAPI thing and I ain't sure the new scheme plays well with the old one for ICC.
I may be missing something obvious here though...3.20.2Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/21828Ninja: MPICH2 and Intel MPI mpif90 breaks Fortran ABI check2021-02-24T10:23:10-05:00Brad KingNinja: MPICH2 and Intel MPI mpif90 breaks Fortran ABI checkCMake + Intel mpif90 + Ninja fails:
```
-- The Fortran compiler identification is Intel ...
...
-- Detecting Fortran compiler ABI info - failed
```
The reason is as follows.
With the Intel Fortran compiler and the Ninja generator, CMa...CMake + Intel mpif90 + Ninja fails:
```
-- The Fortran compiler identification is Intel ...
...
-- Detecting Fortran compiler ABI info - failed
```
The reason is as follows.
With the Intel Fortran compiler and the Ninja generator, CMake explicitly preprocesses Fortran sources like this:
```console
$ ifort -fpp -E src.F > src.F-pp.f
```
The redirection of stdout to a file is needed because `ifort`'s `-E` option is documented as "Causes the preprocessor to send output to stdout". There is no way to tell the compiler to write the preprocessor output directly to a file.
Since !2716, first included in CMake 3.14, CMake passes the `-v` flag when compiling the ABI check in order to extract the implicit include directories that `ifort -v` prints to stderr. That causes the explicit preprocessing step to look like this:
```console
$ ifort -fpp -v -E src.F > src.F-pp.f
```
CMake captures the `-v` output on stderr to extract the implicit include directories.
However, this breaks when using Intel MPI's `mpif90`. It interprets the `-v` flag to mean two things:
* Write version information to stdout.
* Invoke the underlying `ifort` compiler with `-v`.
The ABI check's explicit preprocessing step:
```console
$ mpif90 -fpp -v -E src.F > src.F-pp.f
```
writes two lines of version of information into `src.F-pp.f`, which of course isn't valid Fortran syntax and doesn't compile.
This can be seen by hand:
```console
$ mpif90 -fpp -v -E empty.F 2>/dev/null
mpif90 for the Intel(R) MPI Library ...
Copyright(C) ..., Intel Corporation. All rights reserved.
# 1 "empty.F"
```3.19.6Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/21735CMake uses deprecated flag `-nofor_main` for Intel Fortran2021-01-25T11:40:19-05:00Matthew ThompsonCMake uses deprecated flag `-nofor_main` for Intel FortranIn testing out Intel OneAPI 2021.1.1 with a code of mine, I saw the build spitting out:
```
ifort: command line warning #10434: option '-nofor_main' use with underscore is deprecated; use '-nofor-main' instead
```
After confirming it was...In testing out Intel OneAPI 2021.1.1 with a code of mine, I saw the build spitting out:
```
ifort: command line warning #10434: option '-nofor_main' use with underscore is deprecated; use '-nofor-main' instead
```
After confirming it wasn't coming from our CMake macros, flags, etc., for Intel Fortran, I believe this is from `Modules/Platform/Linux-Intel-Fortran.cmake`
```cmake
string(APPEND CMAKE_SHARED_LIBRARY_CREATE_Fortran_FLAGS " -nofor_main")
```
We do make `TYPE SHARED` libraries so this makes sense why it could pop up.
I went back in time on an old cluster that I still have access to and that has old Intels and it looks like `-nofor-main` (with dash) was supported in Intel Fortran 10 (Intel Fortran 9 had `-nofor_main` in its manpage).
As I believe no one in their right mind should still be using Intel 9 (heck, Intel 17 should be avoided), it's probably safe to just change the flag by fiat, but if you want to still allow it, I think Intel 10 might be a good place to split the CMake.3.19.4Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/21634FindMPI: cmake error when trying to use Intel MPI 2021.12021-03-26T05:49:15-04:00مهدي شينون (Mehdi Chinoune)FindMPI: cmake error when trying to use Intel MPI 2021.1```CMAKE
cmake_minimum_required(VERSION 3.16)
project( bug_mpi_intel C )
find_package( MPI REQUIRED )
```
```SHELL
mkdir build && cd build
cmake ..
-- The C compiler identification is GNU 9.3.0
-- Detecting C compiler ABI info
-- Detec...```CMAKE
cmake_minimum_required(VERSION 3.16)
project( bug_mpi_intel C )
find_package( MPI REQUIRED )
```
```SHELL
mkdir build && cd build
cmake ..
-- The C compiler identification is GNU 9.3.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
CMake Error in /mnt/d/dev/Bugs/build/CMakeFiles/CMakeTmp/CMakeLists.txt:
Imported target "MPI::MPI_C" includes non-existent path
"/mnt/d/dev/Bugs/'/opt/intel/oneapi/mpi/2021.1.1/include'"
in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:
* The path was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and references files it does not provide.
CMake Error in /mnt/d/dev/Bugs/build/CMakeFiles/CMakeTmp/CMakeLists.txt:
Imported target "MPI::MPI_C" includes non-existent path
"/mnt/d/dev/Bugs/'/opt/intel/oneapi/mpi/2021.1.1/include'"
in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:
* The path was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and references files it does not provide.
CMake Error at /home/mehdi/.local/lib/python3.8/site-packages/cmake/data/share/cmake-3.18/Modules/FindMPI.cmake:1213 (try_compile):
Failed to generate test project build system.
Call Stack (most recent call first):
/home/mehdi/.local/lib/python3.8/site-packages/cmake/data/share/cmake-3.18/Modules/FindMPI.cmake:1264 (_MPI_try_staged_settings)
/home/mehdi/.local/lib/python3.8/site-packages/cmake/data/share/cmake-3.18/Modules/FindMPI.cmake:1529 (_MPI_check_lang_works)
CMakeLists.txt:5 (find_package)
-- Configuring incomplete, errors occurred!
See also "/mnt/d/dev/Bugs/build/CMakeFiles/CMakeOutput.log".
```3.19.3https://gitlab.kitware.com/cmake/cmake/-/issues/21340VS generator skips /Z7 flag for Intel Fortran projects2020-10-23T08:44:53-04:00Volker JachtVS generator skips /Z7 flag for Intel Fortran projectsHi,
I have been unable to make CMake set the `/Z7` flag to Intel Fortran projects in Visual Studio.
For example:
```
cmake_minimum_required(VERSION 3.8)
project(test Fortran)
set(CMAKE_Fortran_FLAGS "${CMAKE_Fortran_FLAGS} /Z7 /MP /ab...Hi,
I have been unable to make CMake set the `/Z7` flag to Intel Fortran projects in Visual Studio.
For example:
```
cmake_minimum_required(VERSION 3.8)
project(test Fortran)
set(CMAKE_Fortran_FLAGS "${CMAKE_Fortran_FLAGS} /Z7 /MP /abcd")
add_executable(test test.F90)
```
All (dummy) flags are passed correcty, but `/Z7` is missing.
![vs](/uploads/ccb551a79033d2b924d5b408e2233958/vs.png)
When using a C++ project, passing `/Z7` works as expected.
I am using VS2017, Intel Fortran 2019 and CMake 3.18.4. Do you have any idea? Thanks and kind regards.3.19.0https://gitlab.kitware.com/cmake/cmake/-/issues/21013Cannot build CMake with Intel compilers (bootstrap issue after commit 033a4b1...2020-07-27T10:48:02-04:00Rémi LacroixCannot build CMake with Intel compilers (bootstrap issue after commit 033a4b12a5e5f67f2f00c23885a3ff04acbeb4cd)Hello,
I think bootstrapping CMake with the Intel compilers got broken in commit 033a4b12a5e5f67f2f00c23885a3ff04acbeb4cd (version 3.17.0 and up).
I can understand why the `std::invoke_result<decltype(&T::get), T>` check was added but ...Hello,
I think bootstrapping CMake with the Intel compilers got broken in commit 033a4b12a5e5f67f2f00c23885a3ff04acbeb4cd (version 3.17.0 and up).
I can understand why the `std::invoke_result<decltype(&T::get), T>` check was added but `#if` condition seems wrong to me:
```
#if (__cplusplus >= 201703L || defined(__INTEL_COMPILER) && defined(__cpp_if_constexpr))
```
This seems to enable the C++17 code-path when compiling with C++11, which causes the check to fail with C++11 flags and prevents the bootstrap to find a C++11-enabled compiler:
```
$ CC=icc CXX=icpc ./bootstrap --parallel=8 --no-system-libs --no-qt-gui -- -DCMAKE_BUILD_TYPE=Release -DCMake_TEST_INSTALL=OFF -DCMAKE_USE_OPENSSL=True
...
Error when bootstrapping CMake:
Cannot find a C++ compiler that supports both C++11 and the specified C++ flags.
Please specify one using environment variable CXX.
```
Best regards,
Rémi3.17.4Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/20880Intel-CXX.cmake needs update to handle C++20 (support starts at 19.0)2020-06-29T08:16:23-04:00Matheus IzvekovIntel-CXX.cmake needs update to handle C++20 (support starts at 19.0)At Modules/Compiler/Intel-CXX.cmake, just needs:
```cmake
if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 19.0.0)
set(CMAKE_CXX20_STANDARD_COMPILE_OPTION "-Qstd=c++20")
set(CMAKE_CXX20_EXTENSION_COMPILE_OPTION "-Qstd=c++20")
...At Modules/Compiler/Intel-CXX.cmake, just needs:
```cmake
if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 19.0.0)
set(CMAKE_CXX20_STANDARD_COMPILE_OPTION "-Qstd=c++20")
set(CMAKE_CXX20_EXTENSION_COMPILE_OPTION "-Qstd=c++20")
endif()
```
And:
```cmake
if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 19.0.0)
set(CMAKE_CXX20_STANDARD_COMPILE_OPTION "-std=c++20")
set(CMAKE_CXX20_EXTENSION_COMPILE_OPTION "-std=gnu++20")
endif()
```3.18.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/20752PCH+ifort: cmake_pch.cxx.o created instead of cmake_pch.hxx.gch when language...2020-06-03T06:04:44-04:00Pavel LiavonauPCH+ifort: cmake_pch.cxx.o created instead of cmake_pch.hxx.gch when language Fortran is added to project and ifort detected.With next code there is no error.
```
project(test CXX)
target_precompile_headers(${PROJECT_NAME} PRIVATE
"$<$<COMPILE_LANGUAGE:CXX>:${CMAKE_CURRENT_SOURCE_DIR}/stdafx-UnitTest.h>"
)
add_executable(... only cpp)
```
But when I cha...With next code there is no error.
```
project(test CXX)
target_precompile_headers(${PROJECT_NAME} PRIVATE
"$<$<COMPILE_LANGUAGE:CXX>:${CMAKE_CURRENT_SOURCE_DIR}/stdafx-UnitTest.h>"
)
add_executable(... only cpp)
```
But when I change project to
```project(test CXX Fortran)```
cmake detects ifort and leads to next error on linking executable on linux with g++.
`cmake_pch.cxx.o: file not recognized: File format not recognized`
With further investigation I found that. with adding Fortran language cmake builds cmake_pch.cxx.o target instead of cmake_pch.hxx.gch for CXX language.
CMake should build gch in both cases.
I'm using CMake 3.17.2 with GCC 5.3.3.17.4Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/20190OptimizeReferences and EnableCOMDATFolding linker options are ignored with "V...2020-01-14T09:01:29-05:00Pavel LiavonauOptimizeReferences and EnableCOMDATFolding linker options are ignored with "Visual Studio 15 2017" generator for Fortran projects.I'm trying to build Fortran projects with generated solution but I found flags missing issue.
1. I added following flags to CMakeLists.txt
`target_link_options(${PROJECT_NAME} PRIVATE ... /OPT:REF;/OPT:ICF; ... )`
2. Then I generated ...I'm trying to build Fortran projects with generated solution but I found flags missing issue.
1. I added following flags to CMakeLists.txt
`target_link_options(${PROJECT_NAME} PRIVATE ... /OPT:REF;/OPT:ICF; ... )`
2. Then I generated soludion from CMakeLists.txt using Visual Studio 15 2017 Win64 generator. Generated *.vfproj contains next strings:
`EnableCOMDATFolding="2"`
`OptimizeReferences="2"`
3. Then I'm trying to build it with following command:
`cmake --build "build_dir" --config "Release"`
As a result: mentioned options haven't passed to link command line and absent at build log. Even more: they were deleted from generated *.vfproj file with visual studio. Maybe there is some kind of verification stage before build itself(formatting of generated *.vfproj is also changed).
So, I guess the problem at stage 2. CMake should generate following:
for /OPT:ICF
`EnableCOMDATFolding="optFolding"`
for /OPT:NOICF
`EnableCOMDATFolding="optNoFolding"`
for /OPT:REF
`OptimizeReferences="optReferences"`
for /OPT:NOREF
`EnableCOMDATFolding="optNoReferences"`
Note: generator NMake Makefiles works well.
I'm using:
CMake 3.13
Visual Studio 15.9.16
parallel studio xe 2017.63.16.3https://gitlab.kitware.com/cmake/cmake/-/issues/19691CMake + Intel 19 + VS 2019 -> Error while determining compiler.2019-09-13T10:49:36-04:00Alexander NeumannCMake + Intel 19 + VS 2019 -> Error while determining compiler.Error: ` error : Element <LanguageStandard> has an invalid value of "Default".`
Relevant Intel issue: https://software.intel.com/en-us/forums/intel-c-compiler/topic/811512
Possible Solution:
Add `<LanguageStandard>stdcpp14</LanguageSt...Error: ` error : Element <LanguageStandard> has an invalid value of "Default".`
Relevant Intel issue: https://software.intel.com/en-us/forums/intel-c-compiler/topic/811512
Possible Solution:
Add `<LanguageStandard>stdcpp14</LanguageStandard>` in `<ClCompile>` to `VS-10.vcxproj.in` in `share/cmake-3.15/Modules/CompilerId`
Probably an Intel integration issue and not a CMake issue? Just documenting here if questions arise.https://gitlab.kitware.com/cmake/cmake/-/issues/19664Fortran INCLUDE not pre-processed when using ninja generator2019-09-04T08:50:25-04:00xburgerhoutFortran INCLUDE not pre-processed when using ninja generatorHi,
We are switching from cmake + nmake to cmake + ninja (on windows) to compile a rather large codebase.
One of the constructions used in our fortran (77) code is to INCLUDE a header with a shared common block. The included file conta...Hi,
We are switching from cmake + nmake to cmake + ninja (on windows) to compile a rather large codebase.
One of the constructions used in our fortran (77) code is to INCLUDE a header with a shared common block. The included file contains a conditional CDEC$ block to set the DLLIMPORT attribute depending on the presence of a define.
Header with shared common block, inside library 'mylib' (the common block is exported using a windows .def file):
```fortran
CDEC$ IF .NOT. DEFINED(mylib_EXPORTS)
CDEC$ ATTRIBUTES DLLIMPORT :: /SHCOMM/
CDEC$ END IF
INTEGER IFAC
COMMON /SHCOMM/ IFAC
```
Usage of the common block from outside 'mylib':
```fortran
SUBROUTINE S1( D )
DOUBLE PRECISION D
INCLUDE 'shcomm.h'
C
D = IFAC * D
C
END
```
A small example project is attached containing the full source code.
When building the project on windows with the NMake generator (and the intel fortran compiler), the headers are correctly processed. However, when using the ninja generator, the export of SHCOMM seems to fail:
```
xilink /nologo CMakeFiles\mylib.dir\mylib\ini.f.obj /out:mylib.dll /implib:mylib.lib /pdb:mylib.pdb /dll /version:0.0 /machine:x64 /debug /INCREMENTAL /DEF:Z:\cmake_fortran_issue\frtinc\src\mylib\exports.def /DEF:Z:\cmake_fortran_issue\frtinc\src\mylib\exports.def user32.lib /MANIFEST /MANIFESTFILE:CMakeFiles\mylib.dir/intermediate.manifest CMakeFiles\mylib.dir/manifest.res
Creating library mylib.lib and object mylib.exp
ini.f.obj : warning LNK4217: locally defined symbol SHCOMM imported in function INI
```
It looks like in the generated rules.ninja, the ```Fortran_COMPILER__mylib``` rule does not pass ```$DEFINES``` to ifort.exe. The fortran file 'INCLUDE'-ing the header with the exported common block will not have it's macros expanded, which in turn causes the missing 'DLLIMPORT', which leads to the linker warning.
It would be very helpful for us to get this working, as the cmake + ninja combination compiles an order of magnitude faster than the cmake + nmake combination. I have included a cmake patch I used that seems to work for our scenario. I don't know the cmake code well enough to judge whether this has any other unwanted side-effects.
Sample project (run again.bat):
[cmake_fortran_issue.zip](/uploads/66ff4f93b87b5ae54ed32b12d0959ce1/cmake_fortran_issue.zip)
Build log:
[log.txt](/uploads/60060b85afbf8a74ad061331e735e34c/log.txt)
CMake patch:
[cmake-fortran.patch](/uploads/01e1b74ff6c1ea69069630a8f344577b/cmake-fortran.patch)3.16.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18855Ninja: Use depfile with Intel Compiler for Windows2019-02-06T10:12:37-05:00Brad KingNinja: Use depfile with Intel Compiler for WindowsWith [ninja PR 1039](https://github.com/ninja-build/ninja/pull/1039) merged, Ninja 1.9 will support the depfiles produced by the Intel Compiler for Windows. This means that with a sufficiently new Ninja, CMake's generator can switch to ...With [ninja PR 1039](https://github.com/ninja-build/ninja/pull/1039) merged, Ninja 1.9 will support the depfiles produced by the Intel Compiler for Windows. This means that with a sufficiently new Ninja, CMake's generator can switch to them over the showIncludes approach.3.14.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18687VS generator selects .vfproj for C project2019-02-06T10:12:40-05:00Brad KingVS generator selects .vfproj for C projectSince #16738 and !643, this code:
```cmake
cmake_minimum_required(VERSION 3.8)
project(Mixed C Fortran)
add_library(fobj OBJECT f.f)
add_library(mixed c.c $<TARGET_OBJECTS:fobj>)
```
causes CMake to generate a `mixed.vfproj` file inste...Since #16738 and !643, this code:
```cmake
cmake_minimum_required(VERSION 3.8)
project(Mixed C Fortran)
add_library(fobj OBJECT f.f)
add_library(mixed c.c $<TARGET_OBJECTS:fobj>)
```
causes CMake to generate a `mixed.vfproj` file instead of `mixed.vcxproj`. The `.vfproj` file does not compile the C sources.3.14.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18570FindMPI + Intel 19 compilers: MPI C/CXX not found2019-06-19T09:44:15-04:00Ajay PanyalaFindMPI + Intel 19 compilers: MPI C/CXX not foundScript to reproduce the problem:
```
cmake_minimum_required (VERSION 3.8.2)
project (Test C CXX Fortran)
find_package(MPI)
```
When using Intel 19 compilers, `find_package(MPI)` produces:
```
-- Could NOT find MPI_C (missing: MPI_C_WOR...Script to reproduce the problem:
```
cmake_minimum_required (VERSION 3.8.2)
project (Test C CXX Fortran)
find_package(MPI)
```
When using Intel 19 compilers, `find_package(MPI)` produces:
```
-- Could NOT find MPI_C (missing: MPI_C_WORKS)
-- Could NOT find MPI_CXX (missing: MPI_CXX_WORKS)
-- Could NOT find MPI (missing: MPI_C_FOUND MPI_CXX_FOUND) (found version "3.1")
```
I print the following:
```
-- MPI_C_FOUND=FALSE
-- MPI_CXX_FOUND=FALSE
-- MPI_Fortran_FOUND=TRUE
```
- This happens only when using `cmake>=3.10`. With `cmake<=3.9`, MPI C/CXX are found.
- Another thing I noticed is this happens when the OS is Ubuntu 17.10 or 18.04.
I do not see this problem on RedHat 6, 7 or on Debian 9.
- Not sure if it matters, but I also tried with `cmake_minimum_required (VERSION 3.11)`
- Manually passing `MPI_C_LIBRARIES` or `MPI_CXX_LIBRARIES` did not help either.
my cmake command: `cmake .. -DCMAKE_C_COMPILER=icc -DCMAKE_CXX_COMPILER=icpc -DCMAKE_Fortran_COMPILER=ifort`
Output of `icc -v`
```
icc version 19.0.0.117 (gcc version 8.2.0 compatibility)
```
- gcc used by Intel compiler driver is installed either manually or using [Spack](https://spack.io) on the different OS tested. When using the default gcc provided by Ubuntu, this problem of not finding MPI C/CXX does not show up.