Problem debugging using IFX and Visual Studio

[FrederikS]

When debugging code compiled with IFX it is not always possible to watch variables of derived types in QuickWatch (and it is not possible to set conditional breakpoints).

It seems like the type information of variables of derived types is sometimes wrong.

The attached example shows the problem: It is only possible to see the value of REC in either SUB1 or SUB2.  I have tried different combinations of Visual studio and IFX. 

Using IFORT it works fine.  

[Devorah_H_Intel]

Thank you for your report. I was able to test it internally, and indeed, there is an issue with values being displayed when debugging with IFX.
I have escalated this issue to our debugger team for a fix. 

[Devorah_H_Intel]

The fix for this issue will be available in the 2025.1 ifx release. 

[IgnazSchiele]

I downloaded 2025.1 of the Intel® oneAPI HPC Toolkit and compiled my code again. There are still a lot of variables which cannot be watched. This includes simple variables like integer.

[andrew_4619]

Previously I have had a large number of debugger watch issues. Having been using  2025.1 since it came out and as yet have not seen any such problems. Maybe posting a small simple test project that shows the problem would be useful. There is maybe some option / style/ constructs that generate the problem.

[IgnazSchiele]

Here is a small example.

What I did:
In Visual Studio I created a new fortran project of type "Main Program Code".
In the one and only source file that is created for the project I deleted all text and pasted the following lines:
===snippet============================================
PROGRAM CONSOLE
CHARACTER CTEXT*(5)

JNUM = 1
CTEXT = 'Hallo'

CALL DUMMY (JNUM,CTEXT)

END PROGRAM CONSOLE

SUBROUTINE DUMMY (JNUM,CTEXT)
CHARACTER CTEXT*(*),CTEXT1*(20)

CTEXT1 = CTEXT
JNUM1 = JNUM

RETURN

ENTRY DUMMY_2 (JNUM2)

JNUM3=JNUM2

RETURN

END
===snippet============================================

I built the program and set a breakpoint at the following line:
CTEXT1 = CTEXT
When I run the program then at this breakpoint everything is fine, both parameters to subroutine DUMMY (CTEXT and JNUM) can be watched in the debugger.
Stepping to the next line changes this: now neither CTEXT nor JNUM can be watched, but are "Undefined address".

[andrew_4619]

Many obsolete features but it seems to work.

[IgnazSchiele]

Sorry, the variable names are confusing.

I cannot watch CTEXT and JNUM.

You watched CTEXT1 and JNUM1. What about CTEXT and JNUM? I can only watch them before the line

CTEXT1 = CTEXT

[andrew_4619]

[JohnNichols]

PROGRAM CONSOLE
    implicit none
    integer JNUM
CHARACTER CTEXT*(5)

JNUM = 1
CTEXT = 'Hallo'

CALL DUMMY (JNUM,CTEXT)
call dummy_2(JNUM + 100)

END PROGRAM CONSOLE



SUBROUTINE DUMMY (JNUM,CTEXT)
implicit none
CHARACTER CTEXT*(*),CTEXT1*(20)
integer JNUM,JNUM1,JNUM2,JNUM3

CTEXT1 = CTEXT
call DUMMY_2(JNUM1)

JNUM1 = JNUM
RETURN
end


subroutine ABC
implicit none
integer jnum2, jnum3

ENTRY DUMMY_2 (JNUM2)

JNUM3=JNUM2

RETURN

END

Microsoft Visual Studio Community 2022 (64-bit) - Preview
Version 17.14.0 Preview 4.0

With latest IFX shows all of the variables.  I realize Steve will tell you it is not supported, it merely worketh. 

[JohnNichols]

I added some modern stuff, and amended the entry statements

CAn you put the Fortran into the proper text block so it shows correctly.  

[JohnNichols]

You have to reach JNUM2 in the code to see the variable. 

[JohnNichols]

Andrew:

Is it not time that Fortran had a proper string variable of long length?

John

[andrew_4619]

Allocatable strings remove all the nonsense of declaring a string and hoping it is big enough.

[IgnazSchiele]

Thank you very much for your comments.
But please let me clear up a misunderstanding: When debugging code that is used in my company I first saw that variables are sometimes not displayed.
I then shortened this code as long as the problem still occurred. This resulted in the code snippet that I used in my message from 23 April 2025.
Even if the code is unattractive and should not have been used like this for a long time: there are thousands of lines of such old code in our company (and I bet in many other companies as well).
I would therefore very much appreciate it if the variables of this code were also displayed in the debugger.

[andrew_4619]

Looking at my second screen grab what is the problem?

[IgnazSchiele]

Another misunderstanding: I can watch the variables where you are at in the debugger ("before line 'CTEXT1 = CTEXT'"). Step to the next line and you will not be able to watch the variables any more.

[andrew_4619]

If the carot is at line 14 , 15 or 17 I can still see all the vars a difference is JNUM goes grey for some reason. Do you see something different?

[IgnazSchiele]

Thank you. Here are three screenprints. The first one (where the debugger is before line 'CTEXT1 = CTEXT') shows that the variables can be watched:

On the second screenprint the debugger is at the next line and at first glance everything seems ok:

It seems that I can watch the variables, but there are these circles with arrows which mean "click to refresh". After clicking on both circles I took the third screenprint that shows that the variables are now unknown to the debugger:

I would like the developers at Intel to look into this. Therefore I will describe the problem again and also use other variable names for the parameters to avoid confusion. Moreover I will add a comment in the code to show at which line the debugger stops to show the variables. Do you have any other ideas how I can make the problem obvious?

[JohnNichols]

Clicking the circular arrows is not required as jnum has come in as subroutine number,  you cannot update it, if it is not updated in the subroutine.  Why they have the circular arrows is beyond me, it has no useful purpose, but be annoying.

Hard rule, leave alone that which is weird. 

[JohnNichols]

At 17 it goes gray because it is inaccessible but not yet cleaned up by GC.