I'm developing in Visual Studio and I'm wondering why when I have a derived type that has a vector of allocatable array as an element visual studio debugger describes the object as an undefined pointer/allocatable even after allocation despite the progrma happy working with the values in the array. However, Visual Sutdio debuger shows the correct values for a vector of a structures containing allocatable arrays. In the example below Visual Studio describes arrayB%a(1)%rec as undefined but correctly displays the values of array(1)%a%rec while printing the correct values of both with the write statement, Does this point to some deeper problem with the structure containing vectors of allocatable arrays? Or is this just some quirk of Visual Studio debugger? And if the later is there some way to get Visual Studio to correctly display the data as the vector of allocatable arrays structure is more convient to my problem.
program scratch implicit none type recType real, allocatable :: rec( :, :, :, :,:,:,:) end type recType type str type(recType) :: a end type type strB type(recType) :: a(2) end type type(str) :: array(2) type(strB) :: arrayB allocate(array(1)%a%rec(2,2,2,2,2,2,2)) allocate(arrayB%a(1)%rec(2,2,2,2,2,2,2)) array(1)%a%rec(1,1,1,1,1,1,1) = 0 arrayB%a(1)%rec(1,1,1,1,1,1,1) = 0 write (*,*) "hello world", array(1)%a%rec(1,1,1,1,1,1,1), arrayB%a(1)%rec(1,1,1,1,1,1,1) end program scratch
That is probably the known bug in VS2017 fortran integrations that has been discussed in several other threads recently.
Maybe read https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/784330#new but there are other threads also
Thanks! But I'm using VS2017 version 15.5.2 so this bug shouldn't apply. I have tested this with intel complier version 18.0 update 1 and 18.0 update 3 (which this page https://software.intel.com/en-us/articles/intel-compilers-integration-support-for-microsoft-visual-s... says is the correct supported version) and I get the same results. The program can work with both array and arrayB but the debugger can only display array and returns undefined pointer for arrayB elements.
Hi, it's a VS integration bug which is not limited to VS 2017 (all versions) but also to VS 2015 (update 3). I can reproduce it with PSXE 2019 initial release VS integration. Please file it as a bug in Intel's OSC with reference to this thread (https://supporttickets.intel.com/?lang=en-US).
It's a pitty. I had similar cases for derived types, where this occured over the last years. It's a weak point in integration. Hopefully Intel team will fix this for all combinations in future. Robust debugging in VS is the only reason for me not to switch completely over to Code::Blocks Fortran.
I was asked to test the FEE-patch with VS 2015. However, VS 2015 (aka v14) seems to work differently to VS 2017. The Intel FEE is not installed as an extension and therefor cannot be uninstalled like written here. I tried to install the unzipped 'FEE_VSIX_v15.vsix' but an error occured. I suggest, that this extions is made only for VS2017 (aka v15).
So, the patch does not work and the issue still exists for VS2015. Anyways, in #3 it is written, that the patch not solves this particular issue.
Best regards, Johannes
I don't think you're encountering the bug that FEE patch addresses, which causes VS2017 to crash. My experience is that the bug it fixes isn't present when using VS2015. You're encountering some different issue. Please reply back to Intel support asking them to try your test case.