Stepping through the code seems to jump around almost randomly

[van_der_merwe__ben]

We are using Visual Studio 2026 version 18.6 and Intel Fortran IFX 2026.0. However, we find that in general using F10 to step through the code seems to randomly (but reproducibly) jump a random line in the file and then next time you press it you see the same thing.

AI says that "IFX's LLVM backend has known debug-stepping regressions in heavily GOTO-based Fortran 77-style code like this routine", but we get this for .FOR, and .F90 files and in files that do not use GOTO.

In general, stepping through code seems to just step all over the place no matter the file. Sometimes bearing a resemblance to the actual code executing, but sometimes the next line is just seemingly random.

This also happened with older Intel 2025.3.

Any ideas about this?

Sadly since you can download the compiler for free, we sadly no longer have premier support.

[van_der_merwe__ben]

Note that this is a debug compile, not optimized, not release mode.

According to AI: "This has been a recurring issue with IFX (LLVM-based)—and not limited to GOTO or F77 code despite what that AI answer claimed."

We have tried various AI suggestions, making sure parallel compile is off, full debug is on, various checks are off, etc. No change.

[Nathan_Kidd]

We are also observing the same strange behavior when stepping over statements during a debugging session. Pressing F10 might not go to the next executable statement in the subroutine, and instead hop to a previously executed statement. F10 again *might* then jump to what should have been the next executable statement. However, the subroutines appear to give the expected result despite the debugger jumping to statements in an unexpected manner.

I am observing the undesirable debugging behavior using VS 2026 professional 18.5.2 and IFX 2026.0.0.

[van_der_merwe__ben]

Yes, the code gives the correct results, but stepping through it jumps all over the place. Oddly enough we cant reproduce it yet with a small project we can send in to support. So we are trying to figure out, is it the parallel compile, the size of the solution, nothing so far has fixed it for the larger solution. Any ideas from anyone about what causes this or how to avoid it would help.

[Nathan_Kidd]

Does your small reproducer have multiple modules in multiple files and also access module data with use, only?

Our large code base accesses module data like this:

use module_name, only : variable_name

The VS2026+IFX 2026.0.0 debugger has issues with resolving variable_name -- you will not see the value of variable_name when you hover over it when debugging, and to see the value in the watch window you must include the module name: module_name::variable_name

So I am wondering if the debugger jumping around is related to resolving module variables exposed by use, only.

[carver]

This is a good point. The issue may be related to how the debugger handles module variables imported with use, only. Testing a project with multiple modules and files could help confirm if the stepping problem is connected to module symbol resolution in IFX 2026.

[van_der_merwe__ben]

Steve Lionel or Ron Green, is there any way you can ask the Intel developers about this issue please? They may know about it, maybe there is a workaround or some idea of the cause or how to prevent it?

[Steve_Lionel]

Ron is no longer participating here and is retired from Intel; I've been retired for almost ten years now and am not a side-channel into Intel. (Nie mój cyrk, nie moje małpy.)  If someone posts a small example that demonstrates the problem, perhaps someone at Intel will pick it up. I can pretty much guarantee that a post describing only symptoms, without a test case, will go nowhere.

Just for jollies, I used the 2026.0 compiler to rebuild a program I use occasionally and stepped through it with F10 - It behaved normally. Back in my work days, I'd suggest that this jumping behavior is most likely to occur when debugging optimized code, but I have never worked on an LLVM compiler, so I have no insight into how it works. All I can say here is that AI is often confidently wrong, and I would never trust a response it gives to such a poorly specified question.

[van_der_merwe__ben]

Thanks Steve, right now we are trying to figure out why this happens with our large solution, but not a smaller version of it. If we can make a smaller version manifest the problem, then we have something we can try and send in to Intel Support. Otherwise we can try and figure out what is different between the two setups. It is a slow time consuming process. Our entire solution has over 2298 Fortran files (counting only .f90, .for, .f) and those are the primary dlls only. And yes I agree, AI many times will say "Change this compile setting, this will definitely fix it.". *sad face*

[Steve_Lionel]

Just to verify, you are building without optimization for debugging, right?

It used to be that one could generate an assembler listing with line number annotation, and this would give you a clue as to what the debugger can see, but LLVM doesn't support this last I knew.  The way the debugger does F10 stepping is that it steps instruction by instruction, looking up the current PC in its table correlating PCs to source lines, waiting to see if the line number changes.  This is why, for example, stepping over a large array assignment can take a long time.

One thing you can try for diagnosis is to open up the Disassembly view in the debugger (Debug > Windows > Disassembly). You should see a source line followed by the instructions for that line. If the source lines don't follow sequentially, then the compiler has reordered or merged computations across source lines, something it generally doesn't do with optimization disabled.

Does this jumping around happen in all parts of the application, or only some? What happens if you link in the DLL code statically rather than as a DLL?

[van_der_merwe__ben]

Steve, this happens in many files, compiled with full debug information or compiled with no debug information. But it does not happen all the time in all files, sometimes the line information is correct. It is exactly reproducible, not random. So this source code::

And then the disassembly is this:

You can see the disassembly does not line up with with code and the source code in the disassembly window does not match the  order of the lines in the source file. It is not caused by multiple files files with similar names, and if I disable debug information for all files except one and rebuild and zap all pdb and output files, the stepping in that file is exactly the same. So it is not PDB size either. The code does produce the correct output, and you can inspect symbols, you just cant step through it well. For some lines ina file the stepping is correct and then at some point start jumping around.

[van_der_merwe__ben]

As best I can determine IFX stores debug information in each OBJ file as it compiles and when it links, this all gets put into the pdb file for the dll. There is no shared larger PDB file that might cause this. I am trying to get the LLVM tools working to show me that information.

[Steve_Lionel]

Embedded PDB info has been the norm for many, many years now. You can ask for a single large PDB, though I doubt that would help.

It feels to me as if the compiler is doing some optimization even at O0. You'd need to provide a test case to Intel before anything could be done about it. (NB: "test case" includes the exact commands used to build the test.)

[van_der_merwe__ben]

For reference our compile arguments are:

/nologo /debug:full /MP /Od /I"C:\KCDev\Client1\main\P-SIM\..\H-SIM\Source_H-SIM" /I"C:\KCDev\Client1\main\P-SIM\..\pfine\includes" /I"C:\KCDev\Client1\main\P-SIM\iface\win" /I"C:\KCDev\Client1\main\P-SIM\include" /DWIN32 /D_WINDOWS /D_MBCS /D_USRDLL /DKCIFORTRAN /DKCX64 /warn:declarations /warn:interfaces /real-size:64 /align:rec1byte /assume:byterecl /iface:mixed_str_len_arg /module:"x64\Debug\hsub\\" /object:"x64\Debug\hsub\\" /traceback /check:pointer /check:bounds /libs:dll /threads /dbglibs /c /4I4 /Qdiag-disable:8291 /Qdiag-error:6717

Next we are trying a small project and see if modules changes things, maybe that causes it.

[van_der_merwe__ben]

We have a smallish project which reproduces will, and will work with our IT to get a support account to send it in.  Will advise here...

[van_der_merwe__ben]

Interestingly, if I run this command: "c:\\Program Files\\LLVM\\bin\\llvm-pdbutil.exe" pdb2yaml --all hcrsub.pdb > x.txt

Then in it I find that for this file generally as the offset goes up, the linestart increases, but there is definitely quite a bit where it seems to jump around. So clearly the whacky offsets are coming from the PDB file. See the excerpt below.

So Lionel you might be right, possibly some sort of additional optimization may be going on but looking at the assembly versus the lines, I think something else must be going on. And it is not random, totally reproducible. it does seem to be more prone to happen with more complex code or code that uses a lot of modules. Simple plain short no module Fortran is generally usually ok-ish.

I google ai'd this, tried half a dozen more ideas and options and "This will definitely fix it" ideas and command switches, to no avail. I think getting support from Intel is our our only option.

- Module: 'C:\KDev\Client1\main\P-SIM\x64\Debug\hcrsub\Bed_Quench.obj'
ObjFile: 'C:\KDev\Client1\main\P-SIM\x64\Debug\hcrsub\Bed_Quench.obj'
SourceFiles:
- 'C:\KDev\Client1\main\H-SIM\source_h-sim\Bed_Quench.f90'
Subsections:
- !Lines
CodeSize: 184138
Flags: [ ]
RelocOffset: 12115072
RelocSegment: 1
Blocks:
- FileName: 'C:\KDev\Client1\main\H-SIM\source_hcr-sim\Bed_Quench.f90'
Lines:

....

- Offset: 67084
LineStart: 248
IsStatement: false
EndDelta: 0
- Offset: 67133
LineStart: 251
IsStatement: false
EndDelta: 0
- Offset: 67182
LineStart: 253
IsStatement: false
EndDelta: 0
- Offset: 67683
LineStart: 175
IsStatement: false
EndDelta: 0
- Offset: 67723
LineStart: 176
IsStatement: false
EndDelta: 0
- Offset: 67758
LineStart: 158
IsStatement: false
EndDelta: 0
- Offset: 67770
LineStart: 161
IsStatement: false
EndDelta: 0
- Offset: 67847
LineStart: 173
IsStatement: false
EndDelta: 0
- Offset: 67887
LineStart: 149
IsStatement: false
EndDelta: 0

 See the excert below 

[BenT]

This example is one file and only 90 lines long and demonstrates the step sequencing problem in the debugger.  Using Visual Studio 2022 and Intel oneAPI 2026.0.  I have not installed the FEE extension yet but from other discussion that extension does not fix the step ordering issue.  Let us know about a possible fix or my whole team of 15 will have to continue using IFORT.

[van_der_merwe__ben]

FEE has nothing to do with the step order, the step order comes from the PDB information.

[Marry-Joseph22]

This usually happens due to debug/build issues, not your code.

Try this:

Turn optimization OFF (/Od)

Ensure debug info ON (/Zi)

Do a full Clean + Rebuild

Delete old .pdb and .obj files

Make sure you’re debugging the correct executable

If it still happens, it’s likely a Intel Fortran Compiler (IFX) + Visual Studio debug symbol mapping issue, not your Fortran code.

[van_der_merwe__ben]

If it was that simple we would all jump for joy. We tried that and just about everything else. At this stage I am still working my IT trying to arrange a support account.

[BenT]

Yes I was submitting a small, self contained, simple example to demonstrate this problem with stepping through code in Visual Studio using Intel IFX 2026.0.  Hopefully this will allow Intel to release a fix in an upcoming patch or release.