- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Uninstalling and reinstalling did not correct the debug problem
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):
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Simple reproducer:
Now IFORT
Note the array is explorable in IFORT build but not in IFX build.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page