Showing results for 
Search instead for 
Did you mean: 
Valued Contributor II

derived type now showing in debug locals window

I have a feeling I have seen this in the forum "recently" but I can't find it.... Consider the follows source which reproduces something I have been seeing today in a more complex real situation. The routines below are all in separate source files (i.e. there are 4 files).

module somedefs
    implicit none
    type thing
        integer :: A
    end type
    type(thing) :: one_thing
    type(thing) :: many_things(10)
end module somedefs 
module dt
    use somedefs
        module subroutine fred()
        end subroutine fred
    end interface
end module dt
submodule (dt) dtsub
    implicit none
    module subroutine fred
        integer  ::  I
        one_thing%A = 1
        I           = 1
        !do I = 1 , size(many_things)
            many_things(1)%A = 1
            many_things(5)%A = 5
    end subroutine fred 
end submodule dtsub
Program test
    use dt
    implicit none
    call fred()
end program test

In the debugger there is no trace of many_things in the locals window. If I add it to watch at any level it is marked as unknown. If I manually add somedefs::manythings(1) to the watch window it is known but if I click the arrow to look inside it visual studio crashes and auto restarts.

The is VS2013 with the latest compiler.

0 Kudos
4 Replies
Valued Contributor III

I can reproduce the problem

I can reproduce the problem and the crash with VS 2015.


0 Kudos
Valued Contributor II

Having size(many_things) in

Having size(many_things) in fred() "fixes it". Glad it is not just me @FF.

0 Kudos
Valued Contributor II

This defect in the

This defect in the integrations is still present in the new 17 update 2 but without the VS crash and burn it would seem.

0 Kudos

I have reproduced the problem

I have reproduced the problem and opened a report for it. The track ID is DPD200414907.



Xiaoping Duan

Intel Customer Support

0 Kudos