Bug 70863

Summary: [F03] Finalization of array of derived type causes segfault
Product: gcc Reporter: Weiqun Zhang <weiqun.zhang>
Component: fortranAssignee: Not yet assigned to anyone <unassigned>
Status: NEW ---    
Severity: normal CC: drikosev, janus, jvdelisle2
Priority: P3 Keywords: wrong-code
Version: 6.1.0   
Target Milestone: ---   
Host: Target:
Build: Known to work:
Known to fail: Last reconfirmed: 2016-04-29 00:00:00
Bug Depends on:    
Bug Blocks: 37336    
Attachments: A program demonstrating the problem.

Description Weiqun Zhang 2016-04-28 20:16:33 UTC
Created attachment 38370 [details]
A program demonstrating the problem.

In the attached program, there is a derived type named c, which contains an array of derived type b.  The finalization of a c object causes segfault.
Comment 1 Dominique d'Humieres 2016-04-29 10:35:14 UTC
Confirmed from 4.9 up to trunk (7.0), finalization not implemented in 4.8, related to/duplicate of pr69298?
Comment 2 janus 2016-12-10 00:33:56 UTC
Slightly reduced test case:


module b_module
  implicit none
  type :: b
     character(len=4) :: name = "none"
   contains
     final :: destroy_b
  end type
contains
  impure elemental subroutine destroy_b (this)
    type(b), intent(inout) :: this
    print *, "destroying b: ", loc(this)
    print *, "       name = ", this%name
  end subroutine
end module


program main
  use b_module
  implicit none
  call f ()
contains
  subroutine f()
    type :: c
      type(b) :: object_b(2)
    end type
    type(c) :: x
    x%object_b(1)%name = "b(1)"
    x%object_b(2)%name = "b(2)"
    print *, 'loc of c     ', loc(x)
    print *, 'loc of b(1)  ', loc(x%object_b(1))
    print *, 'loc of b(2)  ', loc(x%object_b(2))
  end subroutine
end


Obviously the second destroyed object has the wrong address.
Comment 3 janus 2016-12-10 00:36:24 UTC
(In reply to Dominique d'Humieres from comment #1)
> related to/duplicate of pr69298?

Yes, I think it's the same problem.
Comment 4 J├╝rgen Reuter 2018-09-28 06:33:24 UTC
Is this code posted October 28 on c.l.f. another incarnation of the same problem?
module third_party_library
  type foo
    integer, pointer :: f(:) => null()
  contains
    final :: foo_destroy
  end type
contains
  impure elemental subroutine foo_destroy(this)
    type(foo), intent(inout) :: this
    print *, "foo"
    if (associated(this%f)) deallocate(this%f)
  end subroutine
end module

module my_code
  use third_party_library
  type bar
    type(foo) :: b(2)
  end type
end module

program main
  use my_code
  type(bar) :: x
  call sub(x)
contains
  subroutine sub(x)
    type(bar), intent(out) :: x
  end subroutine
end program
Comment 5 Ev Drikos 2020-12-16 01:33:05 UTC
(In reply to janus from comment #3)
> (In reply to Dominique d'Humieres from comment #1)
> > related to/duplicate of pr69298?
> 
> Yes, I think it's the same problem.

It's my impression that these examples run ie with '-O3': 

macbook:finalizers suser$ gfc -O3 pr70863-02.f90 && ./a.out > /dev/null
macbook:finalizers suser$ gfc -O3 pr70863-04.f90 && ./a.out > /dev/null
macbook:finalizers suser$ gfc -O3 pr69298-06.f90 && ./a.out > /dev/null
macbook:finalizers suser$ gfc -O3 pr82996-00.f90 && ./a.out > /dev/null
macbook:finalizers suser$ gfc -O3 pr82996-01.f90 && ./a.out > /dev/null
macbook:finalizers suser$ gfc -O3 pr82996-02.f90 && ./a.out > /dev/null
macbook:finalizers suser$ gfc -O3 pr82996-10.f90 && ./a.out > /dev/null

Whereas, Valgrind reports no errors. Any ideas?

Hope this helps
Ev. Drikos