Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29262 Discussions

Debugging host associated variables in XE 2011

Ralf
Beginner
945 Views
Hi all,
I'm having trouble to see host-associated variables in the debugger.

I understand that this was an issue in previous versions - has it been fixed since ? I use IntelVisual Fortran Composer XE 2011, 12.0.3470.2010 andMS Visual Studio 2010 on Windows 7 64bit.
Cheers
-Ralf
0 Kudos
8 Replies
Steven_L_Intel1
Employee
945 Views
I just tried it with 12.0.1 (what I have at home) on Win7 x64 and a simple test case worked. Please try 12.0.2 (current update) and if you have problems proivide us a test case to look at.
0 Kudos
Ralf
Beginner
945 Views
Thanks Steve,
I use the latest update - I included a simple case, see below. The host-associated subroutine in the main program shows the variable 'Plane' correctly.
The host-associated module procedure 'Internal2' does not show the value of the variable in the debugger.
Cheers
-Ralf
[bash]module mod_HostTest
  
  implicit none
  private
  public :: checkMod

  contains

  subroutine checkMod(Plane)
     
     character(*), intent(in) :: Plane
     write(*,*) 'checkMod ',Plane
     Call Internal2()
     !
     contains

        subroutine Internal2()
           ! This does not work anymore: the variable PLANE is not visible in the debugger.
           write(*,*) 'Internal2 ',Plane
        end subroutine Internal2
  end subroutine checkMod

end module mod_HostTest


program HostTest
!*
! Test program for debugging host-associated variables, which do
! not show up correctly in the debugger using IVF XE-2011 12.0.2.
!*
   use mod_HostTest, only: checkMod

   implicit none

   character(2) :: Plane

   Plane = 'XY'
   call Internal1()
   call checkMod(plane)

   ! Internal procedures.
   contains
   
      subroutine Internal1()
         ! This works: the variable shows correctly in the debugger.
         write(*,*) 'Internal1 ',Plane
      end subroutine Internal1

end program HostTest[/bash]
0 Kudos
Ralf
Beginner
945 Views
ps. I use the following compiler options which are needed in the actual project:


/debug-parameters:all /warn:declarations /warn:unused /warn:uncalled /warn:interfaces /heap_arrays /assume:realloc_lhs /stand:f03
0 Kudos
Steven_L_Intel1
Employee
945 Views
Interesting. It works when I build a 32-bit app - I can see the value of PLANE in both procedures - but not when I build a 64-bit app. I "see" the variable but it shows as "undefined address'. Is that what you are seeing? I reported that as issue DPD200166992.
0 Kudos
Ralf
Beginner
945 Views
Hi Steve,
that is exactly what I see as well - I did not realize that the 32-bit app let me see the variable, that's good news.
Thanks
-Ralf
0 Kudos
Ralf
Beginner
945 Views
Hi Steve,
I included a more complicated example using an allocatable derived type - in which case the 32bit app also says 'undefined pointer/array' when looking at 'myType' in the debugger in subroutine 'Internal2'.
The example is closer to the actual code I'm dealing with:
Cheers
-Ralf
[bash]module mod_HostTest
  
  implicit none
  public
  
  type Stuff
     character(2) :: Plane = ''
  end type Stuff
  
  !
  contains
  !

  subroutine checkMod( myStuff )
     implicit none
        
     type(Stuff), intent(inout) :: myStuff(:)
     
     write(*,*) 'checkMod ',myStuff(1)%Plane
     call Internal2()

     !
     contains
     !
        subroutine Internal2()
           write(*,*) 'Internal2 ',myStuff(1)%Plane
        end subroutine Internal2
  end subroutine checkMod

end module mod_HostTest


program HostTest

   use mod_HostTest

   implicit none

   type(Stuff), allocatable :: myStuff(:)

   allocate( myStuff(1) )
   myStuff%Plane = 'XY'

   call Internal1()
   call checkMod( myStuff )

   !
   contains
   !
      subroutine Internal1()
         write(*,*) 'Internal1 ',myStuff(1)%Plane
      end subroutine Internal1

end program HostTest
[/bash]
0 Kudos
Steven_L_Intel1
Employee
945 Views
Ralf,

Your original example is fixed in Update 4 but your newer one is not - sorry about that. I will notify the developers. New issue ID is DPD200168848.
0 Kudos
Steven_L_Intel1
Employee
945 Views
It turns out I was not testing with the final Update 4. Both programs can be debugged correctly with Update 4, which should be out in a week or two.
0 Kudos
Reply