Debugger problem with assumed-length CHARACTER dummy arguments with ALLOCATABLE actual in Intel Fortran Compiler 15

[FortranFan]

Consider the simple code shown below.  The debugger hover and watch functionality in Visual Studio doesn't show the correct value for the assumed-length CHARACTER dummy argument when the actual argument has the ALLOCATABLE attribute.  I'm using Intel Fortran Compiler 15, Update 1.  But I think the problem is present in compiler 15, initial release too.

   MODULE m
   
      !..
      IMPLICIT NONE
      
   CONTAINS
   
      SUBROUTINE foo(String)
       
         IMPLICIT NONE
         
         !..
         CHARACTER(LEN=*), INTENT(IN) :: String
       
         !..
         PRINT *, " foo: String = ", String
         
         !..
         RETURN
          
      END SUBROUTINE foo 
      
   END MODULE m

   PROGRAM p
   
      USE m, ONLY : foo
      
      IMPLICIT NONE
   
      !..
      CHARACTER(LEN=:), ALLOCATABLE :: s
      
      !..
      s = "Hello World!"
      
      CALL foo(s)
      
      !..
      STOP
   
   END PROGRAM p

Is this a known issue?  Any fix for this?

[Kevin_D_Intel]

Hi FortranFan - I do not have any indications about a pending fix for either issue at this time. Development noted it is possible both may share a common underlying root cause. I requested a current status update and will update you about any new information that I receive.

[FortranFan]

Patrick,

Thanks for the feedback even though it is most disappointing.  I'm surprised more users have not reported the same issue or chimed in on this thread because as you can see from the code snippet in the original post and my subsequent quotes, it is quite generic with CHARACTER types and ALLOCATABLE attributes and it is nothing specific or unique to my situation.  I makes me wonder if I am the only person out there using Visual Studio 2012/2013 IDE with the need to watch CHARACTER type with ALLOCATABLE attribute in the debugger!

[johnyb_]

Hi FortranFan,

you are not alone :-). I found your post while searching the forum as I see the same problem with ifort 16.0 and VS2012 while trying to debug problems with user defined type I/O.

Even in the simple test case illustrated below, the allocatable character is not displayed by the debugger.

It worked in VS2010:

I can not try newer versions of VS at the moment. This is certainly an annoying problem.

[FortranFan]

Johny,

Thanks for reporting your findings.  If more users would follow your example, perhaps the matter will gain higher priority at Intel resulting in a speedier resolution.

[Kevin_D_Intel]

Thank you for the additional report Johny. I'm sorry this continues to be unresolved. I added your case to DPD200363559 which is tracking Fortranfan’s earlier case.

Also, I revisited both test cases for the two internal tracking ids I filed earlier this year. Case DPD200363559 (corresponding to the details in post #13) is still not resolved in PSXE 2015 Update 4 or PSXE 2016. The case of DPD200363557 (corresponding to the details in post #10) is unchanged in PSXE 2015 Update 4; however, it behaves better with PSXE 2016.

For DPD200363557 with PSXE 2016, when stopping at the statement SUBROUTINE foo, under the Locals view, the variable String’s value says "Undefined address" and the type field is blank. If I continue to a breakpoint at the PRINT, String’s value and type are correct in the Locals view. When stopping at the statement SUBROUTINE foo, I do not believe the arguments have been evaluated yet so the undefined address might be expected.

I asked Development for and update and clarification about the status of both issues. I will post another reply with any new information.

[Paul_Anton_L_]

Interesting. I've had the same problem for months, only now realizing it's a common problem. I've seen that what the contents of the CHARACTER variable is, depends on where the break point is places. print *, myvar seems to be correct; the string shown in the debugger is quite different from what I'd expect. I've seen this with VS 2013 and Intel 2015 (not sure about further details).

[Johannes_Rieke]

Dear all,

I stumbled today on the debugger issue too. My case is very similar to FortranFan's but make use of character arrays. In VS2015 Professional (14.0.23107.0 D14REL) the debug information is visible by hover and watch within the subroutine where I allocated the character array. Unfortunately it could not be visualized in parent subroutine (array is given as parameter in an explicit interface/ same module). Window print is working correctly. In VS2010 Professional it works as expected. In both cases I use PSXE 2016 (16.0 initial release).

I'm not sure whether the combination of VS2015 and PSXE 2016 is mentioned above (covered by DPD200363557?) or whether it does matter.

Hopefully this is solved in PSXE 2016 Update 1...

[Kevin_D_Intel]

Prior to your reply, I at least had not evaluated any of the issues discussed in this post under VS2015 since that had not been released yet. I just confirmed the issues FortranFan described in post #13 and johnyb in post #24 are reproducible under VS2015 plus PSXE 2016.

Development updated both internal tracking ids this morning.

DPD200363557 is now closed as fixed in PSXE 2016 based on my description in post #26.
DPD200363559 is closed with a fix expected in PSXE 2016 Update 1. This should resolve the behavior described in both FortranFan’s post #13 and johnyb’s post #24.

While evaluating their fix, the debugger team identified another issue from johnyb’s testcase in post #24. That issue involves variables AS and S not having the correct values during the second invocation of the subroutine. On the second call the evaluation of those variables shows the values from the first call. A new internal tracking id (as noted below) was created to track/resolve this new issue.

PSXE 2016 Update 1 is scheduled for release next week so if you can try that once available and report back on whether your unique case is also resolved that would be appreciated. If you can provide a small reproducer then we could check sooner whether Update 1 will resolve your case or not.

(Internal tracking id: DPD200575849 - FEE: Character evaluation fails if calling the same subroutine twice)

[Johannes_Rieke]

Dear Kevin,

many thanks for the update. I was able to produce a minimum working example of the malfunction of the debugger. First, I was confused, because the debugger works in a simple example. I modified the example step by step to reproduce the original code and found out, that the issue only occurs if both subroutines are in the same module and the character array variable is in the parameter list. Please, look into the attachment for details.

Hopefully this helps to find a solution.

Regards, Johannes

[Johannes_Rieke]

Hi all,

after installation of 16.0.1 the integration into VS2015 resolves the problem I described in post #30. The character array is now correctly shown in hover over and in watch list. Thanks for the fix!

Best regards, Johannes

[FortranFan]

Excellent!  Finally I'm happy to report the problem in the original post as well as in Message #13 have been fixed with compiler 16, update 1 - I confirmed this with Visual Studio 2012 SP5, 2013 SP5, and 2015.

[johnyb_]

Nice, my test in #24 also now displays correctly, with VS2012 SP4

[Kevin_D_Intel]

Thank you everyone for confirming the fix appears in PSXE 2016 Update 1. We will keep you updated regarding resolution of DPD200575849 mentioned earlier.

[Kevin_D_Intel]

The final issue (DPD200575849) the debugger team found as noted in post #29 was fixed in 16.0 update 2.

[FortranFan]

Kevin D (Intel) wrote:

The final issue (DPD200575849) the debugger team found as noted in post #29 was fixed in 16.0 update 2.

Thanks Kevin for the update.

Please note though the same kind of issues as seen in the original post of this thread are encountered with the newer standard features such as ASSOCIATE, BLOCK, SELECT TYPE constructs, etc. and with polymorphic variables and so forth.  From a 'helicopter' perspective, Intel integration with VS mainly supports code during program animation (what some call 'debugging') at the Fortran 95 level with some Fortran 2003/2008 features

Take this thread, it is extremely time-consuming for anyone in my situation to present information at such a basic level in the form of a minimal reproducer as shown posted in the original post to get the Intel Fortran team to fix the problem many months or years later.

What I am hoping for is better foresight and product stewarship so that Intel developers can anticipate the needs of developers in line with newer features in the Fortran standard, that the VS integration enhancements needn't follow the implementation with such significant time gaps, that with some imagination, the Intel Fortran team should be able to project out and visualize how customers will use such features in their actual code and animate using VS to understand and validate their programs.

Thanks,