Runtime error with nested derived types and bound procedures

[MDK]

I've searched the forum but haven't seen this exact problem described. If I have a derived type that has a derived type component, calling a type-bound procedure of the component results in an infinite recursion followed by a runtime error.

[plain]module nested_types

    type foo_t
        integer :: i = 0
    contains
        procedure :: do_foo
    end type

    type bar_t
        type(foo_t) :: foo
    contains
        procedure :: do_bar
    end type

contains

    subroutine do_foo(this)
        implicit none
        class(foo_t), intent(inout) :: this
        this%i = 1
    end subroutine
    
    subroutine do_bar(this)
        implicit none
        class(bar_t), intent(inout) :: this
        write (*, *) "begin do_bar..."
        call this%foo%do_foo()               ! 'do_bar' enters a recursive loop here
        write (*, *) "foo%i = ", this%foo%i  ! ...and this line is never reached
    end subroutine
    
end module

program ifort_bug
    
    use nested_types
    implicit none
    type(bar_t) :: bar
    call bar%do_bar()

end program[/plain]

Visual Studio debugger output:

First-chance exception at 0x7c912dcf in ifort_bug.exe: 0xC00000FD: Stack overflow.
First-chance exception at 0x004a7535 in ifort_bug.exe: 0xC0000091:Floating-point overflow.
First-chance exception at 0x7c90e8e5 in ifort_bug.exe: 0xC0000005: Access violation writing location 0x00030f68.
Unhandled exception at 0x7c90e8e5 in ifort_bug.exe: 0xC0000005: Access violation writing location 0x00030f68.
The program '[3916] ifort_bug.exe: Native' has exited with code 0 (0x0).

A workaround for trivial cases is to use basic module procedures and generic interfaces rather than type-bound procedures, but I don't know if this will work for advanced object-oriented code using extended types with abstract interfaces and procedure overriding.

[Steven_L_Intel1]

Very interesting. We'll take a look.

[rogcar]

Quoting - Steve Lionel (Intel)

Very interesting. We'll take a look.

Actually, this is the same problem I reported some days ago. The IVF writes a kind of function table, but they all get the same address. That's why they look recursive. Instead of calling the other function, as it should, it ends up calling itself.

Regards,
Roger

[MDK]

Quoting - rogcar

Actually, this is the same problem I reported some days ago. The IVF writes a kind of function table, but they all get the same address. That's why they look recursive. Instead of calling the other function, as it should, it ends up calling itself.

Regards,
Roger

Yes, exactly. The type-bound bound procedures all have the same address according to the debugger. (Although the debugger doesn't always display accurate information, but that seems to be a known issue.)

[Steven_L_Intel1]

Roger, which issue do you think this is? I see this one you entered, but on first glance they don't seem to be the same.

[rogcar]

Quoting - Steve Lionel (Intel)

Roger, which issue do you think this is? I see this one you entered, but on first glance they don't seem to be the same.

Hello Steve

I was trying to find where I post it, but I could not. Nevertheless, notice what abhimodak said in this post (the one you put). It is the same problem that MDK is reporting, and, as you said back there, you have already reported it to developers.

I hopethat this problem is solved in the next update, looking foward for it :)

Best regards,
Roger

[Steven_L_Intel1]

The issue from the other thread is not going to be in Update 3. It might make it in update 4. I will see if these are the same issue - still not clear to me that it is.

[Steven_L_Intel1]

The issue in THIS thread appears to be fixed in update 3, which should be appearing any day now. The debugger display is still wrong, but the code works. The issue from the other thread is not fixed in update 3.