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

VS2015/PSXE2017U4 integration bug in debugger variable watch

Johannes_Rieke
New Contributor III
476 Views

Hi all, the debugger is not able to show components of the derived type variable node_data within the subroutine sub_print in hover over and watch list (VS 2015 Version 14.0.25431.01 Update 3, PSXE2017 Update 4 17.0.4.210). The attached screenshots show the erroneous display of sub components number and pos.

Please, Intel team fix this issue. IMHO it would be very nice to get full debug watch functionality for VS IDE. I know MS is not making it easy for third party integration, but maybe VS should not be Intel's preferred IDE for Windows in future? Have you ever thought on supporting officially Eclipse or Code::Blocks in future? Maybe in addition?

Try the following minimum working example:

module mod_types
  use ISO_FORTRAN_ENV, only : rk => real64
  implicit none  
    
  type node_data_t
    integer , allocatable, dimension(  :) :: number
    real(rk), allocatable, dimension(:,:) :: pos
  end type node_data_t
  
  
end module mod_types
module mod_subs
  use mod_types
  implicit none
  
  
  contains
  
  subroutine sub_print(node_data)
    implicit none
    type(node_data_t), intent(in), dimension(:) :: node_data
    
    write(*,*) node_data(1)%number
    write(*,*) node_data(1)%pos(1:3,1)
    
    return
  
  end subroutine sub_print
  
  subroutine sub_fill(node_data)
    implicit none
    type(node_data_t), allocatable, intent(out), dimension(:) :: node_data
    
    integer            :: i
    integer, parameter :: len_data  = 5
    integer, parameter :: len_data2 = 10
    
    allocate(node_data(len_data))
    do i = 1, len_data
      allocate(node_data(i)%number(len_data2))
      allocate(node_data(i)%pos(3,len_data2))
      node_data(i)%number = 99
      node_data(i)%pos    = 42.0_rk
    end do
    
    return
  
  end subroutine sub_fill
  
  
end module mod_subs
program DerivedTypeAllocatableDebugger
    use mod_types
    use mod_subs
    implicit none

    ! Variables!
    
    type(node_data_t), allocatable :: node_data(:)

    ! ----------------------------------------------------------------------------------
    
    ! Body of DerivedTypeAllocatableDebugger
    write(*,*) '*** DerivedTypeAllocatableDebugger ***'
        
    call sub_fill(node_data)
    call sub_print(node_data)
    
    continue

end program DerivedTypeAllocatableDebugger
0 Kudos
6 Replies
Devorah_H_Intel
Moderator
476 Views

Hello Johannes,

Thank you for your report! This issue is better to be reported via our Online Service Center at https://supporttickets.intel.com/  
Instructions on how to file a ticket are available here: 
https://software.intel.com/en-us/articles/how-to-create-a-support-request-at-online-service-center  

Best regards,

0 Kudos
Johannes_Rieke
New Contributor III
476 Views

Dear Devorah, thanks for your reply. To be honest I'm confused by your answer. I thought, issues, defects, problems with the compiler and the VS integration should be posted in this forum, so that it can be reviewed and someone of the Intel team can file a bug, if it's really a bug. Have you changed this lately? Was it ever meant to be this way?

At the moment the forum is the only way to get knowledge of bug fixes, since the fixes list (e.g. https://software.intel.com/en-us/articles/intel-parallel-studio-xe-2017-composer-edition-compiler-fixes-list) is not maintained regularly. Kevin and Steve had updated all the threads in near past, if a fix was available. I really appreciate this. How else can other users with the same issue be informed?

Nevertheless, it will take me double time to do so (forum post + creating a support ticket). I'm not sure whether I'm willing to do that...

0 Kudos
andrew_4619
Honored Contributor II
476 Views

johannes k. wrote:
Nevertheless, it will take me double time to do so (forum post + creating a support ticket). I'm not sure whether I'm willing to do that...

Dear Intel, I have said it before and I will say it again. This new policy might save you some work but is not friendly to your customers for all the reasons previously stated and will ultimately be counter productive. 

0 Kudos
Devorah_H_Intel
Moderator
476 Views

johannes k. wrote:

  it will take me double time to do so (forum post + creating a support ticket). I'm not sure whether I'm willing to do that...

Johannes,

Thank you again for the report.  I am going to escalate this to development for the fix.

Best regards,

0 Kudos
Devorah_H_Intel
Moderator
476 Views

I have escalated this issue to development. Regarding the Online Service Center (OSC) submission, it is 1-to-1 support.  I think you'll feel more comfortable on sharing some of your project information there, too. There is a “customer priority” field for each issue at OSC that helps us more accurately prioritize your issue.  We will be continuing monitoring the forum, but for issues that will take much longer time to isolate and back & forth communication, or issues with the sensitive code, please use OSC. The OSC is easy to use tool.  For more information, please see the Online Service Center FAQ, https://software.intel.com/en-us/faq/online-service-center.

 

0 Kudos
Johannes_Rieke
New Contributor III
476 Views

Dear Devorah, thanks for escalation the issue to the development team.

I understand Intel's wish to make things easier to track, but hopefully you understand also the arguments from me, which seems to match to Andrews. Unless the fix list is not re-introduced, no one else, than the OSC ticket opener will be informed about an solution, or am I wrong?

I'm looking forward into a future, where a good solution for both sides is found.

Best regards, Johannes

 

0 Kudos
Reply