character array dynamic allocation debugging

[jr00]

Noticed this odd behavior with the attached sample code below in IVF 11.1 + VS2008; looking at dynamically allocating a character array from an assumed shape string array passed to a function.  The write staement produces the intended output "test string" but watching the value of 'test' in the 'atest' function always produces non-printing character garbage. Cleaning and re-building the solution has no effect and creating a completely new solution changes the value of 'test' in the debugger, but does not correct the issue.

[mecej4]

I have IVF11.1.070 but I no longer have VS2008 installed. The input string str is shown correctly when I use IVF11.1.070 with VS2012. However, the result string test is shown as containing garbage (uninitialized?) in the Locals and in the Watch windows, as you reported.

With the current 14.0.1.139 compiler and VS2012, the error in displaying test is still present, but now the value is shown as "undefined pointer/array", even when compilation has been done with /Zi /Od.

This information may not be enough for you, but it does indicate that the problem is not specific to the 11.1.070 compiler or the version of Visual Studio used.

[Lorri_M_Intel]

Since 11.1 came out 3+ years ago, there have been several improvements to the debug information for allocatables.

With 14.0.1, when entering the subroutine, yes, the local variable "test" is undefined, because it is unallocated (not-yet allocated?)

However, if you step further in the subroutine, it is allocated, VS2008 shows it defined, although the contents are garbage (expected, because our allocation routines do not pre-set the memory to zero). 

A few more steps, and you can watch the string being copied, one character at a time.

But, that is with 14.0.1, not with 11.1.  I think if you're unable to upgrade, you might be stuck with the bug.

                 --Lorri

[jr00]

I am stuck with 11.1 for a while.

Recall the output to stdout is correct with IVF 11, so is the bug in the compiler or the VS debugging tools that show the garbage? Furthmore, will re-building code in release mode based on the test case produce robust & reliable results?

[Lorri_M_Intel · Accepted solution]

I think you have two questions here; let me rephrase, and address them in reverse order.
If I have restated them incorrectly, I apologize.

RE: Will building this test case in release mode produce correct results?
   I would expect that to be true.  The actual runtime code that is generated is independent of debug code generation, although optimizations can affect the resulting runtime code (of course).

RE: Since the correct value is written to the console, what causes the bug?
    Debug information needs to be represented in a canonical form, applicable to the platform.  Then the debugger(s) there needs to be able to read and display that canonical form.   On Windows, the canonical form is quite C-centric and Fortran allocatable types are an extension.  We provide a tool that plugs into the Visual Studio debugger that knows how to read these extensions and display them to the user.
    So.  Where was the bug?  At this point, I can't say whether the compiler generated an ill-formed extension, or the tool misread a well-formed extension.  Both things have happened in the past.

Bottom line, the debug information generated is separate from the runtime code that is generated, and a problem in one does not necessarily infer a problem in the other.

          Does this help?

                              --Lorri
 

[jr00]

Thank you very much for the clear and thorough explanation. Please post any further information to this thread if and when it becomes available.