Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29145 Discussions

ifx 2025.1 fails under Windows with a string macro defined

Dandy_E_
New Contributor I
2,089 Views

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.

 

Labels (1)
1 Solution
Shiquan_Su
Moderator
799 Views

The issue is fixed in the next product release. Thanks for reporting this issue.


View solution in original post

0 Kudos
11 Replies
Dandy_E_
New Contributor I
1,287 Views

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

 

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,987 Views

Nice analysis of the issue.

 

What happens when compiling with the new compiler, but using the older fpp.exe?

 

Jim Dempsey

0 Kudos
Dandy_E_
New Contributor I
1,590 Views

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.

0 Kudos
Jacob_Williams
New Contributor II
1,975 Views

We are seeing the same or similar issue. So we can't update to 2025.1 until we have a fix or workaround.

jimdempseyatthecove
Honored Contributor III
1,948 Views

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

 

0 Kudos
Dandy_E_
New Contributor I
1,836 Views

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.

0 Kudos
Shiquan_Su
Moderator
1,758 Views

Thanks for catching this bug. What is your Windows OS version and Visual Studio version? Our preferred VS version is at least 2022.


0 Kudos
Dandy_E_
New Contributor I
1,630 Views

@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.

 

 

0 Kudos
Dandy_E_
New Contributor I
1,287 Views

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 show_args.exe @arguments.rsp, the first argument the program gets is @arguments.rsp. Thus handling the content of arguments.rsp is expected to be done by the callee. In powershell that does not work that simple, but I did not bother to find out how it would work.

 

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.

0 Kudos
Shiquan_Su
Moderator
1,263 Views

I confirmed I met the same linking error using your reproducer with oneAPI 2025.1. I have passed the issue to the developer.


0 Kudos
Shiquan_Su
Moderator
800 Views

The issue is fixed in the next product release. Thanks for reporting this issue.


0 Kudos
Reply