Viewing submodule variables in the debugger?

[Frank_J]

Has anyone discovered how to view submodule variables in the debugger?

[Shiquan_Su]

Would you please provide a solution .sln as a reproducer to showcase your issue?

[Nathan_Kidd]

Since IFX 2025.3 we have lost the ability to hover over variables to see their values. If you have module data exposed like this:

use module_name, only : variable_name

 You can view the variable's value in the watch window if you prepend the module variable:

module_name::variable_name

@Shiquan_Su , @AlexM1 provided reproduction steps that @yzh_intel confirmed. Please see this post:

community.intel.com/t5/Intel-Fortran-Compiler/Observation-If-ONLY-used-in-subroutine-then-variables-will-NOT/m-p/1747942#M178866

[Shiquan_Su]

Thanks, @Nathan_Kidd .

Hi, @Frank_J , would you please test the solution in the post Nathan mentioned? If it is the same fix. I will mark this as solution.

[Nathan_Kidd]

Hi @Shiquan_Su , please do not consider this issue fixed. I consider prepending the module name in the watch window a workaround to an unfortunate regression in the debugging experience.

I hope that it is a priority for the next version of IFX and/or FEE to restore our debugging capabilities.

[Frank_J]

@Nathan_Kidd describes the method for viewing module variables. As far as I can tell there is no way of viewing submodule variables. There hasn't been a consistent method since submodules were introduced in ifort. At one point it seemed that a submodule variable used in the procedure being debugged could been seen by hovering over it but I'm not sure how reliable it was and it can't be done now. I don't believe there is a way of viewing a submodule variable that corresponds to the viewing of a module variable by prepending the module name and ::.

[Shiquan_Su]

I see. In this case, would you be able to create a small reproducer of a solution .sln to showcase your issue? We can start working on it from there.

[Frank_J]

Attached is an example. I've checked it using ifx 2026.0.0 in VS 2022. In this example the submodule variable can be viewed from a procedure in which it is referenced but not from a procedure in which it isn't. If it were a module variable it could be viewed using the documented "specify the module name, followed by "::", followed by the variable name" but there doesn't seem to be an equivalent for submodule variables.

[Shiquan_Su]

Hi, Frank:

I use Visual Studio 2022, oneapi 2026.0, latest FEE.

I can see the submodule_variable in watch window.

You can start by adding a print statement in the submodule as a guide. But later even you remove that print statement, things still work. I attached my screenshot here.

[FortranFan]

@Frank_J ,

Please see this comment at a related thread:

https://community.intel.com/t5/Intel-Fortran-Compiler/Observation-If-ONLY-used-in-subroutine-then-variables-will-NOT/m-p/1743972/highlight/true#M178658

May you please post the specific details of your environment on the Visual Studio version, Intel Fortran (IFX) version, the situation with Extensions in Visual Studio, particularly the Intel Fortran Expression Evaluator?  And add some screenshots of a debug session in Visual Studio with a Fortran codebase, as shown in the above thread?  This will help Intel team including @Shiquan_Su to follow up on the problem.

Please note this aspect with debug support around Intel Fortran integration with IFX and the Visual Studio IDE is extremely important to quite a few customers of Intel, including a team I work with who have inherited a couple of critical codebases and who are otherwise always looking for the next big language to port the codebase over and who can't stand Fortran, unfortunately!

Declining support around debugging of Fortran code and Intel Fortran processor in Visual Studio IDE - at least what appears as such with IFX - makes matters a whole lot worse, particularly for managers and enterprises who continue to rely on Fortran codebases.

Collecting and sharing all the issues with Intel Fortran team around IFX and Visual Studio debugger on Windows is thus essential.

Thank you for this thread.

[FortranFan]

@Frank_J ,

Separately, please note the following works as expected i.e., an object local to a module subroutine hosted in a submodule is viewed in the Watch window and inspected by hovering the mouse over a reference to the object (e.g., 'msg' object in the snip below).

 

The above snip is from an environment running

• Visual Studio 2026 v18.5.1
• Intel Fortran 2026.0
• Intel Fortran Expression Evaluator 2025.2.2

It will be useful to get clarity around your specific situation.

[Frank_J]

Two scenarios illustrate the issue:

1)  Add a breakpoint to the commented line in procedure TryViewingSubmoduleVariable.

      Start Debugging (F5).

      When the program breaks at the breakpoint the variable submodule_variable is not viewable in a Watch window or by hovering over a reference to the variable. See Image_1.

2)  Add breakpoints to the commented lines in procedures SetSubmoduleVariable and TryViewingSubmoduleVariable.

     Start Debugging (F5).

     When the program breaks at the first breakpoint the variable submodule_variable is viewable in a Watch window and by hovering over a reference to the variable. See Image_2.

     Continue (F5).

     When the program breaks at the second breakpoint the current value of the variable submodule_variable is not available in the Watch window (indicated by the variable name and its last known value being greyed) or by hovering over a reference to the variable. (The current value is 5.) See Image_3

Were submodule_variable a module variable its current value would be accessible when the program breaks at the breakpoint in the procedure TryViewingSubmoduleVariable by prepending the variable name with the module name followed by :: in the Watch window. There is no equivalent reference for a submodule variable.

A workaround is to place submodule variables in a module. But forcing a particular form of coding to accommodate the failings of the debugger is not really satisfactory.

Note that this is a very simple example. I have instances in much larger code bases in which a submodule variable is not accessible in the debugger at all.

[Shiquan_Su]

Hi, Frank:

This is the current implementation limitation. We see that Visual Studio only keeps track of the variable values in the "active" frame/scope. When the control flow moves to another frame/scope, the variables and values in the "inactive" frame will lose the update.

The module case is actually a group of situations that the module somehow stays active when the control flow steps into another frame/scope.

Shiquan

[Frank_J]

I assume when you say scope you are referring to the functioning of the debugger, as the scope, in a Fortran sense, of submodule variables is the submodule and its submodules, if any. Is it too naive to ask for the values of submodule variables to be accessible in the debugger in a similar manner to module variables?