Compiler bug (?) with type-bound procedures and pointers

[MDK]

[plain]module ifort_bug_mod

    implicit none
    
    type :: foo_t
        integer :: i = 999
    contains
        procedure :: write_foo
    end type
  
    type :: bar_t
        type(foo_t), pointer :: pfoo => null()
    end type
  
        
contains

    subroutine write_foo(this)
        implicit none
        class(foo_t), intent(in) :: this
        write (*, *) this%i
    end subroutine
    
end module


program ifort_bug

    use ifort_bug_mod
    
    implicit none
    
    type(foo_t), target :: foo
    type(foo_t), pointer :: pfoo
    type(bar_t) :: bar
    
    pfoo => foo
    bar%pfoo => foo
    
    call write_foo(pfoo)      ! ok
    call write_foo(bar%pfoo)  ! ok
    call pfoo%write_foo()     ! ok
    call bar%pfoo%write_foo() ! error
    
end program[/plain]

If I try to access a type-bound procedure using a pointer to the type that is itself a type component, I get garbage results as if the target of the pointer is undefined. Calling the type-bound procedure through a plain pointer produces the correct result, as does calling the procedure as a regular procedure--e.g. 'sub(foo)' rather than 'foo%sub()'--using either the plain pointer or a pointer that is a type component. I'm using 11.1.051.

[abhimodak]

Some additional observations that may help Intel:

If I watch the value of this%i in the debugger, I see that for ALL the calls the value is garbage. For the first three calls where the printed answer looks ok, the debugger shows this%i = 4944540 while for the last call it shows 4944564.

Similar to this, the "value" of the procedure write foo is also same (#004B7288) while being different (#004B7290). Before the call is made for all combination, %i and %writefoo are 999 and #004D5000.

Of course, I don't think that the specifics are important here but it just hightlights that even though the printed values are correct for first three cases not all is good on the debugger level.

Abhi

[Steven_L_Intel1]

Thanks - we'll take a look.

[Steven_L_Intel1]

This looks similar to issue DPD200140796 but I'm not yet certain.

[Steven_L_Intel1]

Yes, it is the same. It is fixed in our sources but I do not yet know when it will appear in a compiler near you. I will post here when I have more information.

[Steven_L_Intel1]

This issue is fixed in 11.1 Update 6, available now.