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

IFX 2025.0 & VS 17.11.3 debugging problem

TiborKibedi1
Beginner
632 Views

It seems there is a problem in debugging using the latest IFX compiler and Visual Studio 2022 Community edition 17.11.3. Using the IFX compiler,  the values of derived type parameters, like A(i)%B(j)%C could not be displayed. However, using IFORT debugging works correctly.

I recall, this was an issue with the previous version of the compiler. IFORT is now depreciated and will be discontinued late 2024. Will this annoying problem width the IFX compiler corrected before the end of the year?

0 Kudos
1 Solution
Mark_Lewy
Valued Contributor I
433 Views

You may need to qualify the variable name with the module name to access it:

If d is in module m then specify m::d in the watch window

 

This works for me with IFX 2025.0 in VS 2022 17.9.2

View solution in original post

7 Replies
Mark_Lewy
Valued Contributor I
567 Views

The validated version of VS 2022 for use with OneAPI 2025.0 is 17.9.2; you are using an unsupported version.

0 Kudos
tkibedi
Novice
481 Views

I tried to download the community edition of the supported VS2022 17.9.2 version, but is not available on the Microsoft web site. I contacted their support and they confirmed that only the Professional or Enterprise edition is available. This would be a significant cost to purchase. By installing the latest community edition of VS2022 and Intel HPC toolkit, IFORT is no longer available. So debugging is not working as reported in my original post.

I am using the intel compiler for many years and I just renewed my licence. Looks like have to wait for a solution from the Intel developers to solve this compatibility issue. However, there is no indication how long it will take.

Is there a link to the previous Intel Fortan compiler version, which has IFORT?

What about new users of the latest Intel Fortran compiler?  They will have no hope, that debugging of a modern code will work, unless they are prepared to purchase a licence for an outdated version of VS2022 professional. 

0 Kudos
tkibedi
Novice
462 Views

I tried to do more tests to identify the problem with debugging. Attached is a simple code, compiled with Intel® Fortran Compiler 2025.0 & Visual Studio Community Edition 17.12.0 on a Win 11 system.

If all declarations are in the main code - as in the attached TestOneApi.f90 source file- all variables can be viewed, including D(i)%Path(j)%x, etc. However putting all variables into a separate source file containing the TestOneApiMod module and accessing it through the USE statment, VS flagging "D" as an "Undefined variable". It is telling me, that if the main member ("D") of a derived type has been declared as an array, the debugging is not working. On the other hand, the compiled code treats correctly  all derived parameters of array D. There might be a simple solution for this.

Mark_Lewy
Valued Contributor I
434 Views

You may need to qualify the variable name with the module name to access it:

If d is in module m then specify m::d in the watch window

 

This works for me with IFX 2025.0 in VS 2022 17.9.2

tkibedi
Novice
425 Views

It works for me in VS 2022 17.12.0, which is the latest version. It is an extra step and was not needed in previous versions. Hopefully will be corrected, perhaps in the next release.

marinoni__andrea_mas
296 Views

Hi I also have this issue, I saw in the forum it was supposed to be fixed with latest release but apparently its not.

It would be very helpful to have a working debugger with current VS or have an installer update that fixes this debugging things.

Is this planned ?

0 Kudos
jimdempseyatthecove
Honored Contributor III
208 Views

NOT FULLY SOLVED

A variation of this problem

While I can examine module variables in the debugger by scoping the variable (myModule::foo), if I have a derived type, typed, in a module, then use that type to declare a variable locally that points to one of those types, then I cannot examine that variable.

jimdempseyatthecove_0-1732116857561.png

TypeObject is declared in a module named MOD_TOSS which is used in this procedure (named TISSV).

Note, the type of pObject should be type(MOD_TOSS::TYPEOBJECT), not scoped to TISSV which is the name of the procedure.

Debugging using UDT's declared within a module is problematic.

 

Selecting ifort as the compiler corrects this issue.

Jim Dempsey

Reply