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

Impossible to see the contents of polymorphic variables in debugger

jean-vezina
Beginner
529 Views

Good afternoon,

I have discovered that the debugger in Visual Studio is unable to display the contents of a polymorphic variable beyond its declared type. In the following example, I define a MAIN root type and extends it in three different manners. The LIST array contains the three examples. When I set a breakpoint at the line of the DO statement, and I try viewing the contents of LIST with the debugger, I can only see the contents of the root type. Same thing if I set a breakpoint in a code line following the ASSOCIATE statement: I cannot go beyond the variable defined in the root type. Is there any way to see the full contents of a polymorphic variable? I am testing the Intel Fortran 2018 beta using Visual Studio 2013.

Thanks in advance,

Jean 

    program derived_type

    type main
        character(10) type
    end type
    type,extends(main):: char_type
        character(10) a
    end type
    type,extends(main)::double_type
        double precision t
    end type
    type,extends(main)::array_type
        real,allocatable::x(:)
    end type
    type multi
        class(main),allocatable::var
    end type
    type (multi) list(3)
    list(1)%var=char_type('character','abcde')
    list(2)%var=double_type('double',4.4)
    list(3)%var=array_type('array',[1.,2.,3.])
    ! Put a breakpoint at the DO: impossible to see beyond the declared type, the dynamic portion is invisible
    do i=1,3
        associate(element=>list(i)%var)
            
            select type(element)
                ! Put a breakpoint on the associate name, also impossible to see beyond the declared type
            type is(char_type)
                print *,element%type,element%a
            type is(double_type)
                print *,element%type,element%t
            type is (array_type)
                print *,element%type,element%x
            end select
        end associate
    end do

    end program derived_type

 

0 Kudos
6 Replies
Kevin_D_Intel
Employee
529 Views

I was able to reproduce this but unable to find a means of accessing those variable's values. I reported this to our Debugger developers and will share with you if there's a syntax for accessing those values. Thank you for the concise reproducer.

(Internal tracking id: DEBGGR-2994)

0 Kudos
Andrew_Smith
New Contributor III
529 Views

I dont get why that even compiles for two reasons.

1. The polymorphic assignment is not supported yet as far as version 17.0.2. maybe 18 beta?

2. The select type construct has no associate name so element should remain a polymorphic entity and then the extended attributes should not be visible and should signal an error on compile.

Having written the usual rather odd set of code to fix issue 1 and added an associate name (e) it runs but the debugger shows odd things for e.

The value of e%type is not even shown correctly.

This makes 2 bugs and I can think of more which I will submit at some point.

DebugTypesFail.png

0 Kudos
FortranFan
Honored Contributor II
529 Views

Kevin D (Intel) wrote:

I was able to reproduce this but unable to find a means of accessing those variable's values. I reported this to our Debugger developers and will share with you if there's a syntax for accessing those values. Thank you for the concise reproducer.

(Internal tracking id: DEBGGR-2994)

But Kevin, is this any surprise though?  My impression has long been that users have requested countless times for Intel Fortran integration with VS to be enhanced and for the debugger to become more 'aware' but version after version update, the most basic of facility with a Fortran 2003 feature is dysfunctional in the VS debugger and that is true even with 18.0 beta in year 2017.  See below for a trivial example.  Intel developer team has to know of these severe limitations and users should not have to request tracking incidents with each of their scenarios.

debug.png

0 Kudos
jean-vezina
Beginner
529 Views

Good evening,

I ran also into this case where it is not possible to see the contents of the result of an allocatable array valued function. The contents of the get_values array cannot be seen in the debugger.

Thanks in advance,

Jean

program debug_array_function

    real,allocatable::f(:,:,:)

    f=get_values(10,10,10)
    contains
    function get_values(n1,n2,n3)
    real,allocatable::get_values(:,:,:)
    ! Impossible to see the values of get_values 
    allocate(get_values(n1,n2,n3))
    get_values=0
    forall(i=1:min(n1,n2,n3))
        get_values(i,i,i)=i
    end forall
    end function
    end program debug_array_function

 

0 Kudos
Kevin_D_Intel
Employee
529 Views

@Andrew – Yes 18.0 Beta provides support of polymorphic assignment with LHS allocatable. Re: SELECT TYPE, it appears within an ASSOCIATE block; therefore, an associate name on the SELECT TYPE is not needed. The Fortran Developers who reviewed the code agreed it is standard conformant and that ifort 18.0 is compiling it correctly and producing the expected run-time results.

@FortranFan – This case involved new support in the 18.0 compiler and it may come down to relating to the ASSOCIATE case you show. I was looking at it more from the case of new language support not being handled.

@jean-vezina – I don’t know whether this is a case previously reported or not. I didn’t find a matching existing report so I reported this to Development also. FWIW, at least for the trivial case, the values of “f” are visible after the function execution.  (Internal tracking id: DEBGGR-2996)

0 Kudos
jean-vezina
Beginner
529 Views

Kevin,

Thanks a lot for your help and support!

Regards,

Jean

0 Kudos
Reply