- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
When compiling with ifx 2025.1.0, the default is a call of ifx with command line arguments:
Deleting intermediate files and output files for project 'Console1', configuration 'Release|x64'.
Compiling with Intel® Fortran Compiler 2025.1.0 [Intel(R) 64]...
ifx /nologo /O2 /fpp /I"long_path_even_longer\include1" /DTRY_BUILD=1 /DMY_INTDIR=\"Release\" /module:"x64\Release\\" /object:"x64\Release\\" /libs:dll /threads /c /Qlocation,link,"C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.42.34433\bin\HostX64\x64" /Qm64 "C:\Users\esc\source\repos\Console1\Console1\Console1.f90"
Linking...
Link /OUT:"x64\Release\Console1.exe" /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"x64\Release\Console1.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /SUBSYSTEM:CONSOLE /IMPLIB:"C:\Users\esc\source\repos\Console1\Console1\x64\Release\Console1.lib" -qnextgen -qm64 "x64\Release\Console1.obj"
Embedding manifest...
mt.exe /nologo /outputresource:"C:\Users\esc\source\repos\Console1\Console1\x64\Release\Console1.exe;#1" /manifest "x64\Release\Console1.exe.intermediate.manifest"
Console1 - 0 error(s), 0 warning(s)
when the command line gets longer (here triggered by excessive include definitions) something in build chain decides that ifx is to be called differently, i.e., ifx @RSP1.rsp:
Deleting intermediate files and output files for project 'Console1', configuration 'Release|x64'.
Compiling with Intel® Fortran Compiler 2025.1.0 [Intel(R) 64]...
Creating temporary file "RSP1.rsp" with contents
[
/nologo /O2 /fpp /I"long_path_even_longer\include1" /I"long_path_even_longer\include2" /I"long_path_even_longer\include3" /I"long_path_even_longer\include4" /I"long_path_even_longer\include5" /I"long_path_even_longer\include6" /I"long_path_even_longer\include7" /I"long_path_even_longer\include8" /I"long_path_even_longer\include9" /I"long_path_even_longer\include10" /I"long_path_even_longer\include11" /I"long_path_even_longer\include12" /I"long_path_even_longer\include13" /I"long_path_even_longer\include14" /I"long_path_even_longer\include15" /I"long_path_even_longer\include16" /I"long_path_even_longer\include17" /I"long_path_even_longer\include18" /I"long_path_even_longer\include19" /I"long_path_even_longer\include20" /I"long_path_even_longer\include21" /I"long_path_even_longer\include22" /I"long_path_even_longer\include23" /I"long_path_even_longer\include24" /I"long_path_even_longer\include25" /I"long_path_even_longer\include26" /I"long_path_even_longer\include27" /I"long_path_even_longer\include28" /I"long_path_even_longer\include29" /DTRY_BUILD=1 /DMY_INTDIR=\"Release\" /module:"x64\Release\\" /object:"x64\Release\\" /libs:dll /threads /c /Qlocation,link,"C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.42.34433\bin\HostX64\x64" /Qm64 "C:\Users\esc\source\repos\Console1\Console1\Console1.f90"
]
Creating command line "ifx @"C:\Users\esc\source\repos\Console1\Console1\x64\Release\RSP1.rsp""
ifx: command line warning #10161: unrecognized source type 'Files\Microsoft'; object file assumed
ifx: command line warning #10161: unrecognized source type 'Visual'; object file assumed
fpp: fatal: can't fopen file: Studio\2022\Professional\VC\Tools\MSVC\14.42.34433\bin\HostX64\x64 /Qm64 C:\Users\esc\source\repos\Console1\Console1\Console1.f90
Console1 - 0 error(s), 2 warning(s)
This fails under the given circumstances.
I boiled it down to the example build attached, where a preprocessor macro is defined that represents a literal string, e.g. /DDEFSTRING=\"string\".
When executing:
ifx @string_macro_exe.rsp.txt
one gets a compiler error:
D:\SharedwLnx\fprograms>ifx @string_macro_exe.rsp.txt && .\string_macro.exe
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2025.1.0 Build 20250317
Copyright (C) 1985-2025 Intel Corporation. All rights reserved.
ifx /fpp "/DDEFSTRING=\string" string_macro.f90 -o string_macro.exe"
ifx: command line error: no files specified; for help type "ifx /help"
As can be seen in line 5: the escaped quotation marks break the build by causing havoc in the argument evaluation (there is a left over backslash and a quotation mark at the end of the line).
Running the same command with ifx 2024.2 gives the expected output
D:\SharedwLnx\fprograms>ifx @string_macro_exe.rsp.txt && .\string_macro.exe
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2024.2.0 Build 20240602
Copyright (C) 1985-2024 Intel Corporation. All rights reserved.
ifx /fpp /DDEFSTRING="string" string_macro.f90 -o string_macro.exe
Microsoft (R) Incremental Linker Version 14.42.34438.0
Copyright (C) Microsoft Corporation. All rights reserved.
-out:string_macro.exe
-subsystem:console
string_macro.obj
DEFSTRING: "string"
at the same time building with command line arguments expanded with ifx 2025.1 works also fine:
D:\SharedwLnx\fprograms>ifx /fpp /DDEFSTRING=\"string\" string_macro.f90 -o string_macro.exe && .\string_macro.exe
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2025.1.0 Build 20250317
Copyright (C) 1985-2025 Intel Corporation. All rights reserved.
Microsoft (R) Incremental Linker Version 14.42.34438.0
Copyright (C) Microsoft Corporation. All rights reserved.
-out:string_macro.exe
-subsystem:console
string_macro.obj
DEFSTRING: "string"
Building via ifx @string_macro_exe.rsp.txt works in all previous compiler versions I tested (includes ifort 2021.1.2, ifort 2021.13.0, ifx 2025.0). As the escaped quotation marks are required to define a literal string, and work fine when given directly on the command line, I assume this change of behaviour was not intended and is a bug.
The reduction of the number of includes is not an option, since the project in which the problem originally occurred is huge, with well organized, but many, cross dependencies. If someone could point me to a solution of how to avoid making the build switch to ifx @RSP1.rsp, I would be grateful.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The issue is fixed in the next product release. Thanks for reporting this issue.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Additional note:
Using string_macro_exe_qloc.rsp.txt with content:
/fpp /c /DDEFSTRING=\"string\" /Qlocation,link,"C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.42.34433\bin\HostX64\x64" string_macro.f90
By running ifx @string_macro_exe_qloc.rsp.txt, the original error in Visual Studio can about exactly be reproduced:
D:\SharedwLnx\fprograms>ifx @string_macro_exe_qloc.rsp.txt
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2025.1.0 Build 20250317
Copyright (C) 1985-2025 Intel Corporation. All rights reserved.
ifx /fpp /c "/DDEFSTRING=\string" /Qlocation,link,C:\Program" Files\Microsoft Visual "Studio\2022\Professional\VC\Tools\MSVC\14.42.34433\bin\HostX64\x64 string_macro.f90"
ifx: command line warning #10161: unrecognized source type 'Files\Microsoft'; object file assumed
ifx: command line warning #10161: unrecognized source type 'Visual'; object file assumed
fpp: fatal: can't fopen file: Studio\2022\Professional\VC\Tools\MSVC\14.42.34433\bin\HostX64\x64 string_macro.f90
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nice analysis of the issue.
What happens when compiling with the new compiler, but using the older fpp.exe?
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I did not try any older fpp.exe, but remembered that ifort, as well as ifx, can be made to produce very verbose output when the argument -# is added.
I thus created fullout_nl.rsp with content:
/fpp
/c
-#
/DDEFSTRING=\"string\"
string_macro.f90
and called: ifx @fullout_nl.rsp
This gives the output:
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2025.1.0 Build 20250317
Copyright (C) 1985-2025 Intel Corporation. All rights reserved.
ifx /fpp /c -# /DDEFSTRING=\string" string_macro.f90
C:\PROGRA~2\Intel\oneAPI\compiler\latest\bin\fpp \
-D__INTEL_LLVM_COMPILER=20250100 \
-D__INTEL_LLVM_COMPILER_UPDATE=0 \
-D__INTEL_COMPILER=20250100 \
-D__INTEL_COMPILER_UPDATE=0 \
-D_WIN32 \
-D_M_AMD64=100 \
-D_M_X64=100 \
-D_WIN64=1 \
-D_MSC_VER=1942 \
-D_MSC_FULL_VER=194234440 \
-D_MSC_EXTENSIONS \
"-D__MS_VC_INSTALL_PATH=C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.42.34433\" \
-D_MT \
-D__INTEL_COMPILER_BUILD_DATE=20250317 \
-D__MMX__ \
-D__SSE__ \
-D__SSE_MATH__ \
-D__SSE2__ \
-D__SSE2_MATH__ \
-D__pentium4 \
-D__pentium4__ \
-D__tune_pentium4__ \
-DDEFSTRING=\string" \
-I. \
...
As you can see line 4 is already corrupted. Thus any fpp.exe called will receive the broken argument -DDEFSTRING=\string" from line 28.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We are seeing the same or similar issue. So we can't update to 2025.1 until we have a fix or workaround.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Try creating "Include.rsp" with the contents of your "/Ixxx" but not the other files (.f90, .lib, etc...)
then issue
ifx @include.rsp ...\console1.f90
alternatively
Perform the compile inside a batch file (or make file) and append the "/I..." options to INCLUDE
SET INCLUDE=$INCLUDE ";I...;I..."
ifx OtherInputsHere
This setting remains valid for the duration of the batch/make file.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for your efforts, but as said above, this compiler bug breaks a Visual Studio build of rather complex project with lots of dependencies. Some of these are external and can not be changed simply, at least not by me. Since the actual command line is generated by the Visual Studio/Intel Fortran build chain, I can not just modify it.
I am well aware of multiple ways to get the reduced example from my original post to work. But this example is just the reduction to the absolute minimum to allow Intel to reproduce the error.
One could for example put string macros into a separate string_macros.fpp file:
#ifndef STRING_MACROS_FPP
#define STRING_MACROS_FPP
#define DEFSTRING="string"
#endif
and include that in the Fortran source file that need it.
But as said, that is not wholly in my hands and would require tedious propagation into numerous external projects.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for catching this bug. What is your Windows OS version and Visual Studio version? Our preferred VS version is at least 2022.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Shiquan_Su wrote:Thanks for catching this bug. What is your Windows OS version and Visual Studio version? Our preferred VS version is at least 2022.
I don't understand why this would matter.
- the minimal example, that reproduces the issue, calls IFX directly, e.g., ifx @string_macro_exe.rsp.txt, w/o involving Visual Studio
- the actual parsing of command lines arguments specified via <command> @file.rsp is not a Windows feature, but has to be done by the called <command>, as far I could gather
But here you are:
Windows 11:
Edition Windows 11 Enterprise
Version 22H2
Installiert am 06.05.2024
Betriebssystembuild 22621.5039
Leistung Windows Feature Experience Pack 1000.22700.1074.0
Visual Studio:
Microsoft Visual Studio Professional 2022
Version 17.12.5
VisualStudio.17.Release.LTSC.17.12/17.12.5+35728.132
Microsoft .NET Framework
Version 4.8.09032
Installed Version: Professional
Visual C++ 2022 00476-80000-00000-AA576
Microsoft Visual C++ 2022
ASP.NET and Web Tools 17.12.178.10385
ASP.NET and Web Tools
Azure App Service Tools v3.0.0 17.12.178.10385
Azure App Service Tools v3.0.0
C# Tools 4.12.0-3.24631.1+da7c6c4257b2f661024b9a506773372a09023eee
C# components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.
Intel® DPC++ Compatibility Tool 2024.1
Intel® DPC++ Compatibility Tool 2024.1, Copyright © 2019-2024 Intel Corporation. All rights reserved.
Intel® Fortran Compiler 2025.1
Intel® Fortran Compiler 2025.1, Copyright © 2002-2025 Intel Corporation. All rights reserved.
Intel® oneAPI Menu & Samples 10.10.392.9731
Intel® oneAPI Visual Studio Menu & Samples Extension
Microsoft JVM Debugger 1.0
Provides support for connecting the Visual Studio debugger to JDWP compatible Java Virtual Machines
NuGet Package Manager 6.12.3
NuGet Package Manager in Visual Studio. For more information about NuGet, visit https://docs.nuget.org/
Visual Basic Tools 4.12.0-3.24631.1+da7c6c4257b2f661024b9a506773372a09023eee
Visual Basic components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.
Visual Studio IntelliCode 2.2
AI-assisted development for Visual Studio.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I already replied to your question on 04-01-2025, but that reply is now gone?! Thus again.
I don't understand why the Visual Studio version is of importance. The example, I provided, calls IFX directly from the command line and does not involve Visual Studio.
The method of passing arguments via a file is not a Windows feature, to me it looks like the callee (here IFX) has to handle that all by himself. At least when I call a simple program from the command line (cmd
But here you are:
Visual Studio
Microsoft Visual Studio Professional 2022
Version 17.12.5
VisualStudio.17.Release.LTSC.17.12/17.12.5+35728.132
Microsoft .NET Framework
Version 4.8.09032
Installed Version: Professional
Visual C++ 2022 00476-80000-00000-AA576
Microsoft Visual C++ 2022
ASP.NET and Web Tools 17.12.178.10385
ASP.NET and Web Tools
Azure App Service Tools v3.0.0 17.12.178.10385
Azure App Service Tools v3.0.0
C# Tools 4.12.0-3.24631.1+da7c6c4257b2f661024b9a506773372a09023eee
C# components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.
Intel® DPC++ Compatibility Tool 2024.1
Intel® DPC++ Compatibility Tool 2024.1, Copyright © 2019-2024 Intel Corporation. All rights reserved.
Intel® Fortran Compiler 2025.1
Intel® Fortran Compiler 2025.1, Copyright © 2002-2025 Intel Corporation. All rights reserved.
Intel® oneAPI Menu & Samples 10.10.392.9731
Intel® oneAPI Visual Studio Menu & Samples Extension
Microsoft JVM Debugger 1.0
Provides support for connecting the Visual Studio debugger to JDWP compatible Java Virtual Machines
NuGet Package Manager 6.12.3
NuGet Package Manager in Visual Studio. For more information about NuGet, visit https://docs.nuget.org/
Visual Basic Tools 4.12.0-3.24631.1+da7c6c4257b2f661024b9a506773372a09023eee
Visual Basic components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.
Visual Studio IntelliCode 2.2
AI-assisted development for Visual Studio.
Windows 11
Edition Windows 11 Enterprise
Version 22H2
Installiert am 06.05.2024
Betriebssystembuild 22621.5039
Leistung Windows Feature Experience Pack 1000.22700.1074.0
Hope that helps.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I confirmed I met the same linking error using your reproducer with oneAPI 2025.1. I have passed the issue to the developer.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The issue is fixed in the next product release. Thanks for reporting this issue.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page