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

IFX debugging issue MS VS

jimdempseyatthecove
Honored Contributor III
1,725 Views

When passing a user defined type or allocatable array to a procedure compiled with IFX, the MS Debugger is unable to expand the contents.

w_HPCKit_p_2022.1.2.116_offline.exe

 

Note, when in the CMD window, as well as from MS VS Help About

the IFX version reports 2022.0.0 Build 20211123

 

What's going on with the version numbers???

 

As a work around, I compile some of the projects using IFORT and the others using IFX.

I cannot do the entire solution in IFORT because IFORT experiences an occasional ICE. 

This ICE is restricted to a single statement, a

    CALL sub(array(:)%var, Iarray, charString, integer(8), integer(8))

If I change the "sub" "nameNotFound", the compile succeeds but the link fails as expected.

.OR.

if I use the correct name, but pass an incorrect type the compiler reports an error as expected.

 

I suspect (presume) IFORT is no longer being maintained, else I might post a reproducer.

 

Jim Dempsey

0 Kudos
14 Replies
jimdempseyatthecove
Honored Contributor III
1,720 Views

Additional follow-up:

Has the array descriptor changed between IFORT and IFX?

 

If I call an IFX procedure from IFORT with an allocatable array (IFORT passes an allocatable array, IFX declares the dummy as allocatable as well), IFX appears to receive it as memory address of the base of the array in IFORT (which may not be allocated). The MS VS debugger shows the type as __int64[0] &.

Additionally, if I force an index out of bounds, e.g array[-3] with bounds checking enabled, I get a memory access error instead of array access out of bounds.

 

I am able to use work arounds (e.g. allocating before call)

 

Jim Dempsey

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,715 Views

Update to the update

subroutine foo(array)

  integer(8), allocatable :: array(:)

 

appears to be passed as if compiled with

  integer(8) :: array(*)

 

Because, if I do size(array), I can see the size of the actual argument (but w/o the bounds I cannot assert correctness via debugger)

 

Jim Dempsey

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,680 Views

RE: debug symbols in IFX showing as __int64[0] & and udt's not explorable

I am uninstalling the Intel products. I have (had)

Intel Parallel Studio XE 2021

oneAPI 2021

oneAPI 2022

 

Possibly one of the earlier installs made the latest install avoid tweaking MS VS 2019

 

I suspect that is not entirely the case.

Reason being the "appears to be passed as if compiled with integer(8) :: array(*)"

Because the size of the array (though not visible via __int64[0]& is obtainable via the size intrinsic.

This indicates that the array(*) format was used on the CALL made from the IFORT side as the hidden size dummy was found.

I will let you know after uninstalls and reinstall of only oneAPI 2022.

 

I do not think that the ICE is related, but who knows.... (The Shadow knows)

 

Jim Dempsey

0 Kudos
Steve_Lionel
Honored Contributor III
1,702 Views

It sounds to me, in part, as if the Fortran debugging support isn't loading, as you're getting C types shown. Does it work for ifort?

To the best of my knowledge, ifort is still being maintained. ifx isn't yet at feature parity with it.

0 Kudos
Barbara_P_Intel
Moderator
1,694 Views

ifort is still being maintained!  Remember that ifort and ifx share the same Fortran front end. Usually I see that if one compiler ICEs the other does, too. 

Do you have a reproducer?

 

 

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,665 Views

Uninstalling and reinstalling did not correct the debug problem

dbg001.jpg

IFX RESTFILERADIXSORT Line 20 calls

IFX UNFORMATTEDFILESORT line 200 calls

IFORT FILERADIXSORT line 4403 calls

IFX DOSYNCHSORT line 4544 calls (this file contains the allocatable array Indicies)

IFX MYSORTSUB_NAME (this procedure is intended to receive the array descriptor and pass it on to RadixSort)

 

The RadixSort routine contains code to examine the Indicies array to see if it is allocated or not then allocate, and if allocated to see if is sized correctly and if not resize.

When DOSYNCHSORT passes (is intended to pass) an unallocated array descriptor to MYRADIXSORT_NAME, and then it passes on to RADIXSORT, RADIXSORT sees the array as allocated with subscripts (1:0).

The original project was configured to compile everything using IFORT, however the line "call RadixSort(..." caused the ICE. Compiling that source using IFX corrected the ICE problem. The project RadixSort is a sort library and I intended to provide this as IFORT compiled.

Now look at this...

If I go up a call stack level from MYSORTSUB_NAME to DOSYNCHSORT (compiled in the same Project):

dbg002.jpg

You can see that the UDT's and arrays are explorable.

I will see if I can reduce this to a small reproducer.

 

Jim Dempsey

 

jimdempseyatthecove
Honored Contributor III
1,661 Views

Simple reproducer:

dbg003.jpg

Now IFORT

dbg004.jpg

Note the array is explorable in IFORT build but not in IFX build.

Jim Dempsey

jimdempseyatthecove
Honored Contributor III
1,639 Views

Also, If I build as IFORT, rename the .pdb to Console1.pdb.IFORT, and build using IFX

Then rename the IFX .pdb to Console1.pdb

Then rename the IFORT .pdb back to Console1.pdb

IOW use the IFORT .pdb with the IFX .exe

The same issue remains.

 

I figured out a work around. (crappy solution but may help your developers isolate the MS VS integration issue).

 

1) Build as IFX

2) Switch compiler to IFORT

3) go into the Configuration Manager and uncheck the Build box (for projects)

4) Start debugging (IOW force the IDE to not rebuild as IFORT but start debugging with projects set as IFORT)

 

The crappy part is I have to do this for all 5 projects (back and forth to each debug cycle).

 

Jim Dempsey

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,633 Views

Now back to the ICE issue with IFORT.

 

Cutting the Solution down to a simple reproducer (I anticipate) will be problematic because in trying to track the issue down, by repositioning code, the same code (in different places) would compile without the ICE.

 

Pairing the Solution down to a simplified reproducer will be problematic.

 

Jim Dempsey

0 Kudos
Steve_Lionel
Honored Contributor III
1,628 Views

I see C types in the Locals window. That tells me that the Fortran expression evaluator is not being loaded. This symptom has shown up for users many times over the years - what usually fixes it is to uninstall both Fortran and Visual Studio, delete the Visual Studio folder, then reinstall.

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,602 Views

>>what usually fixes it is to uninstall both Fortran and Visual Studio, delete the Visual Studio folder, then reinstall.

Did this yesterday (MS VS took 6 hours to install). Same issue with Debug arrays and UDT's in IFX.

I sent the ICE reproducer into the support center, let's see if they can locate the issue.

I will plug along using a mix of IFX and IFORT

Jim Dempsey

 

 

 

0 Kudos
JohnNichols
Valued Contributor III
1,591 Views

It should not take 6 hours to uninstall and reinstall the entire system. Two hours tops.  I do it at least once a week on a computer, even a NUC i3 is quick.  What version Windows and computer are you using?  

 

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,621 Views

I'll give that a try (another waste of a couple of hours).

Hopefully that will fix it.

I did the uninstall/reinstall of the Intel products, but not MS VS itself.

I hope it reinstalls....

 

Jim Dempsey

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,583 Views

Distro of MS VS is online installer, files to download = 36.5GB (all tools), ISP download rated at 7Mb/sec...

but actual speed much lower from MS server -> ISP -> MS VS Installer (averaged 1.35Mb/sec)

Jim Dempsey

0 Kudos
Reply