Issues Debugging Dynamically Allocated Arrays with IFX Compiler

[Vivid]

Hi 

I was using the IFORT Fortran compiler. Recently, I switched to the IFX compiler and encountered issues when debugging dynamically allocated arrays. Previously, I used pointer functions for dynamic allocation or defined structures through modules and then dynamically allocated them, and there were no issues viewing the values of these arrays during debugging. However, with the IFX compiler, only the pointer function displays values during debugging. The "debug all," "check all," and "traceback" options are enabled.

For example, within the module, I store properties such as arrays, sizes, and names using the type. Therefore, I have information like A.Arr(1), A.SizeA, and A.Name. However, I cannot view any of the information related to A. In contrast, the IFORT compiler was able to display all the information.

Thank you

[andrew_4619]

Does it work with A%Arr(1),  A%SizeA, and A%Name which is the standard conforming way? 

[Vivid]

Thank you for showing interest in my question. I found the solution in another post on the Intel forum. The solution was to use module_A::A or module_A::A%Arr when using module_A.

Thank you.

[andrew_4619]

Yes that is a common workaround used in many instances over a long period. The debugger is meant to resolve references directly without needing the module, hopefully that will be fixed some day. With IFX we have taken a step backwards in this regards.

[JohnNichols]

Yes, this problem has been addressed in earlier forum posts. As Andrew notes it is a bit annoying.  If you are looking at a particular value, then use the window to point to the value, you will never scroll through the huge arrays.  Better yet write out the array to a file and then look.  I was working with 52 million data points and this is not searchable in VS. 

I had posted a comment about IFX and IFORT in terms of the comment by 

“all conservatism is based upon the idea that if you leave things alone you leave them as they are. But you do not. If you leave a thing alone you leave it to a torrent of change. If you leave a white post alone it will soon be a black post. If you particularly want it to be white you must be always painting it again; that is, you must be always having a revolution. Briefly, if you want the old white post you must have a new white post.”

G K Chesterton from the early 1930's. The point of the post is to say that IFX is a step forward with the 64 bit, but a step backward in the time needed to add in all the functions etc... that take time to write and then debug, IFORT is a white post, we all like it, but IFX is the new black post, we do not like and it needs a lot of effort to become white and effective. Of course this forum is the Intel Canary in the gold mine, with many people looking at the compiler, hence providing Intel with an inexpensive testing team.  Interestingly, the moderators deleted the earlier post, it must have been too obtuse. 

The real question is when will Fortran move to 128 bit? 

[jimdempseyatthecove]

>>The real question is when will Fortran move to 128 bit?

use real(16)

or if you prefer

integer, parameter :: QPkind = SELECTED_REAL_KIND(13*2) ! real(QPkind)

current Intel CPUs emulate 128-bit in software.

Jim Dempsey