One %grab too many

[sfilippone]

One %grab too many

[sfilippone]

On further reflection, this really depends on what happens upon execution of register_self
subroutine register_self (this)
class(universal), intent(inout) :: this
this%counter = ref_counter(this)
end subroutine

The assignment is the routine
subroutine assign (lhs, rhs)
class (ref_counter), intent(inout) :: lhs
class (ref_counter), intent(in) :: rhs
print*, 'assign in ref_counter'
lhs%count => rhs%count; lhs%obj => rhs%obj
call lhs%grab; end subroutine

and the RHS is declared to be intent(in), so during the execution of the assignment it is not changed.
What happens to the RHS after the completion of the assignment?
Is the associated memory copied and then released? It does not look so, because the assignment is only assigning pointers.

IF the RHS is freed, THEN there is a need for an extra %grab in new_ref_counter. Otherwise, not.
Could it be that different compilers have different ideas on how to implement this particular aspect?
GNU seems to work fine without the %grab in new_ref_counter.
It looks like there are differences with Intel.
More research is needed

[sfilippone]

Confirmed.
GNU does not need the extra grab().
Intel does need the extra grab().
Tests with other compilers might be useful, but I would tend to attribute this to a bug in GNU.
Notice that the function new_refcounter_type has an ALLOCATABLE return value, so it makes sense for it to deallocate the RHS.

[sfilippone]

Further inquiry has shown that:

1. The result of new_refcounter_type does not need to be allocatable
2. GNU executes fewer finalization calls than Intel; I suspect a GNU bug
3. For the time being I have put an #ifdef for GNUC and the code works correctly for both GNU and Intel.

[sfilippone]

module test_type_mod

type :: my_test_type
integer, allocatable :: i
contains
final :: delete_test_type
end type my_test_type

interface my_test_type
module procedure new_test_type_object
end interface my_test_type

contains

subroutine delete_test_type(this)
type(my_test_type) :: this

write(*,*) 'Called delete_test_type'
if (allocated(this%i)) deallocate(this%i)

end subroutine delete_test_type

function new_test_type_object(item) result(res)
type(my_test_type) :: res
integer, intent(in) :: item
!Allocation on assignment
res%i=item
end function new_test_type_object

end module test_type_mod

module target_mod
use test_type_mod
type :: outer_type
type(my_test_type), allocatable :: test_item
end type outer_type

contains

subroutine new_outer_type(outer,item)
type(outer_type), intent(out) :: outer
integer :: item

allocate(outer%test_item)
write(*,*) 'Assigning outer%test_item'
outer%test_item = my_test_type(itemi)
write(*,*) 'End of new_outer_type'

end subroutine new_outer_type

end module target_mod

program testfinal
use target_mod

implicit none

integer :: i=10
type(outer_type), allocatable :: wrapper

write(,) 'Allocating wrapper '
allocate(wrapper)
write(,) 'Calling new_outer_type '
call new_outer_type(wrapper,i)
write(,) 'DeAllocating wrapper '
deallocate(wrapper)

end program testfinal

[sfilippone]

The previous is a self-contained code.
With GNU it prints the following output
[sfilippo@lagrange newstuff]$ ./testfinal
Allocating wrapper
Calling new_outer_type
Assigning outer%test_item
End of new_outer_type
DeAllocating wrapper
Called delete_test_type

i.e. the FINAL subroutine is called once

With Intel:
[pr1eio03@login1: newstuff]$ ./testfinal
Allocating wrapper
Calling new_outer_type
Assigning outer%test_item
Called delete_test_type
Called delete_test_type
End of new_outer_type
DeAllocating wrapper
Called delete_test_type

i.e. the FINAL subroutine is called THREE times.
Clearly, Intel and GNU can NOT both be right (and I suspect GNU is at fault).
The extra (or missing) FINAL invocation is the reason why I need to (un)comment the call to %grab in ref_counter.f90

[rouson]

@sfilippone the test suite now contains compiler tests that excute automatically with fpm test and document a few orthogonal issues with any compilers that fail any of the tests. The README.md file documents the compiler status for ifort, gfortran, and nagfor. Currently NAG's nagfor compiler is the only one with zero test failures. I'll work on seeing whether we can get the fort and gfortran bugs fixed.