topic Re: Re:ifx 2025.1 fails under Windows with a string macro defined in Intel® Fortran Compiler

ifx 2025.1 fails under Windows with a string macro defined

Dandy_E_ — Thu, 27 Mar 2025 16:19:51 GMT

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.

Re: ifx 2025.1 fails under Windows with a string macro defined

Dandy_E_ — Thu, 27 Mar 2025 16:44:31 GMT

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

Re: ifx 2025.1 fails under Windows with a string macro defined

jimdempseyatthecove — Fri, 28 Mar 2025 13:35:00 GMT

Nice analysis of the issue.

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

Jim Dempsey

Re: ifx 2025.1 fails under Windows with a string macro defined

Jacob_Williams — Fri, 28 Mar 2025 14:33:14 GMT

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

Re: ifx 2025.1 fails under Windows with a string macro defined

jimdempseyatthecove — Fri, 28 Mar 2025 16:36:40 GMT

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

Re: ifx 2025.1 fails under Windows with a string macro defined

Dandy_E_ — Mon, 31 Mar 2025 08:07:24 GMT

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.

Re:ifx 2025.1 fails under Windows with a string macro defined

Shiquan_Su — Tue, 01 Apr 2025 23:31:34 GMT

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

Re: Re:ifx 2025.1 fails under Windows with a string macro defined

Dandy_E_ — Wed, 02 Apr 2025 09:40:24 GMT

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

Re: Re:ifx 2025.1 fails under Windows with a string macro defined

Dandy_E_ — Fri, 04 Apr 2025 11:42:25 GMT

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

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.

Re: ifx 2025.1 fails under Windows with a string macro defined

Dandy_E_ — Tue, 08 Apr 2025 08:08:16 GMT

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.

Re:ifx 2025.1 fails under Windows with a string macro defined

Shiquan_Su — Mon, 28 Apr 2025 20:38:01 GMT

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

Re:ifx 2025.1 fails under Windows with a string macro defined

Shiquan_Su — Thu, 05 Jun 2025 19:30:20 GMT

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

Re: Re:ifx 2025.1 fails under Windows with a string macro defined

DirkvanMeeuwen — Wed, 16 Jul 2025 08:11:56 GMT

@Shiquan_Su : Is this included in 2025.1.1? I still get the issue:

Creating temporary file "RSP1.rsp" with contents [ /nologo /debug:full /MP /Od /fpp /I"C:\myIncludes" /I"C:\myIncludes/Debug" /DNO_MATLAB /DNO_UMFPACK /Dx64 /DCMAKE_INTDIR=\"Debug\" /Qopenmp /module:"..\mod\Debug" /object:"MessageHandlerStatic.dir\Debug\\" /traceback /libs:dll /threads /dbglibs /c -Zi /heap-arrays /real-size:64 /c /Qmkl:parallel /Qdiag-disable:5462 /warn:all /Qlocation,link,"C:\ProgramFiles\MicrosoftVisualStudio\2022\Professional\VC\Tools\MSVC\14.42.34433\bin\HostX64\x64" /Qm64 "C:\MHS\Source\m_loghandler_file.f90" "C:\MHS\Source\m_loghandler_stdout.f90" "C:\MHS\Source\m_logger_interface.f90" "C:\MHS\Source\m_loghandler.f90" "C:\MHS\Source\m_loghandler_callback.f90" ] Creating command line "ifx @"C:\build\MHS.dir\Debug\RSP1.rsp"" ifx: command line error: no files specified; for help type "ifx /help"

Re:ifx 2025.1 fails under Windows with a string macro defined

Shiquan_Su — Wed, 16 Jul 2025 13:46:13 GMT

Unfortunately, when we reached the fix around the June 5th time frame, we had already passed the code change cutoff for oneAPI 2025.2, released in June. So this fix will be included in the next oneAPI product release, oneAPI 2025.3, around Oct/Nov 2025.

Re: Re:ifx 2025.1 fails under Windows with a string macro defined

Daniel_Dopico — Wed, 05 Nov 2025 12:33:19 GMT

I have just tried the 2025.3 and probably the issue is fixed and I say probably because now my code triggers a new ICE, not present in 2024.1.

I had to try several times in two different computers, updating to 2025.3 and rubbing my eyes several times: believe it or not, the code that was compiling in 2024.1 throws an ICE in 2025.3.

I don't know how you guys achieved this but, in the same update that you solved a serious issue, you managed to break something else. I am quite used to find bugs in the compiler but I think this is one of the few times that a new ICE arises without touching the code.

Now the difficult part: I'll try to issolate the new bug and report it, but it can be difficult or even impossible. I am stuck in old versions which don't work in windows 11.

Re: Re:ifx 2025.1 fails under Windows with a string macro defined

Dandy_E_ — Fri, 07 Nov 2025 12:42:02 GMT

I assume ICE being an internal compiler error?

Re: Re:ifx 2025.1 fails under Windows with a string macro defined

Shiquan_Su — Thu, 18 Dec 2025 19:57:32 GMT

Hi, Daniel:

The ICE is a different issue from the previous path parsing issue. Let's put the path issue behind.

For the new ICE issue, would you please submit a new ISVC ticket to provide more details?

Would you please try:

1. Turn on debug symbols in your compile flag to print out more debug info.

2. Turn on verbose to print out the exact compile line command that meets the ICE.

3. Change different optimization levels among -O0, -O1, -O2, -O3. Does the ICE show up in the same place for every optimization level?

4. Can you share the source code file that meets the ICE?