Software Archive
Read-only legacy content
17061 Discussions

Easy access to variables in modules

Knut_G_
Beginner
521 Views

Hello world,

I have been searching around and I have come so far as to find that one can have access to module variables in the watch window through modulename::variable, which helps.

Is it possible to get this as a mouse-over as well? We have a large code base with legacy code so it happens that one has to debug unfamiliar code. It is very useful to be able to glance through variables to see what they contain. It is possible to use the watch window, but it takes much longer time.

I am also having trouble debugging when in a contained subroutine. I have to jump across the stack to maybe get access to a variable which should be in scope, ex:

module my_module

use statements
use more, only: statements

integer, allocatable :: shared_values(:,:)

!some code doing something
call a_contained_routine()

contains

subroutine a_contained_routine()
!variables

call suba()
call subb()

end subroutine

subroutine suba()
!variables

where (shared_values<0) shared_values=0
end subroutine

subroutine subb()
!do smtn
end subroutine

end module

In such a setup I would have troubles debugging the values in shared_values and often have to introduce a local copy just to see the contents. Code is always executed as expected, I just have trouble seeing it.

Regards, Knut

PS: Currently using Visual Studio 2013 for debugging, code is compiled with Intel Fortran 14.0.2.176 build 20140130. I also have Parallel Studio XE 2016 with ifort 16.0 build 20151021 but our code does not compile with an internal compiler error so I have not tried debugging with the latest and greatest.

0 Kudos
1 Solution
Georg_Z_Intel
Employee
521 Views

Hello Knut,

I've talked with one of our FEE engineers.

How the tool tip works is implemented by VS. FEE (our component) only provides information how to evaluate whatever VS detects under the mouse pointer (plain strings w/o context). Unfortunately we cannot add an improvement here because of the missing context.

The issue with contained subroutines is known and currently in queue to improve debug information at compiler side. See also:
https://software.intel.com/de-de/forums/intel-visual-fortran-compiler-for-windows/topic/594809

It's still being worked on.

I've been told that modulename::variable was explicitly implemented to overcome the debug information issue, so one can at least evaluate the contents of a module.

Best regards,

Georg Zitzlsberger

View solution in original post

0 Kudos
3 Replies
Georg_Z_Intel
Employee
522 Views

Hello Knut,

I've talked with one of our FEE engineers.

How the tool tip works is implemented by VS. FEE (our component) only provides information how to evaluate whatever VS detects under the mouse pointer (plain strings w/o context). Unfortunately we cannot add an improvement here because of the missing context.

The issue with contained subroutines is known and currently in queue to improve debug information at compiler side. See also:
https://software.intel.com/de-de/forums/intel-visual-fortran-compiler-for-windows/topic/594809

It's still being worked on.

I've been told that modulename::variable was explicitly implemented to overcome the debug information issue, so one can at least evaluate the contents of a module.

Best regards,

Georg Zitzlsberger

0 Kudos
Knut_G_
Beginner
521 Views

Hello and thank you,

Ok, would that mean that if VS changed the string from the mouse pointer to reflect module, you could get at the contents? I'm guessing it would be low priority, but could VS have this information? List of all variables for each use statement. I am unsure of where VS information stops and Intel plugin starts.

Looking forward to improved support for contained routines/functions.

0 Kudos
Georg_Z_Intel
Employee
521 Views

Hello Knut,

how strings are selected is up to VS. It will stop at some delimiters and does not have any knowledge about Fortran syntax/semantic at all. In addition, the API does not have any functionality to get what's beyond the delimiters for extended context (IIRC).

Hence it will only get some string that's evaluated in the current context (i.e. call stack and instruction pointer). FEE has to obey.

Best regards,

Georg Zitzlsberger

0 Kudos
Reply