Hi Andre,
> so when I interpret the testcase correctly, than the finalizer should not be
> called, right? So adding a call abort() in the Finalize and allocating and
> deallocating M in the main program should do no harm, but make the testcase
> IMO
> more feasible. What do you think?
thanks for the comment. Indeed it can not hurt to extend it into a
runtime test. New version attached (according to your suggestions). Ok
with this?
Cheers,
Janus
> On Thu, 8 Dec 2016 13:56:29 +0100
> Janus Weil <[email protected]> wrote:
>
>> Hi all,
>>
>> the attached patch fixes an ice-on-valid problem with finalization.
>> The ICE turned out to be caused by a bug in 'has_finalizer_component':
>> According to the documentation, this function is supposed to detect
>> whether a derived type has any nonpointer nonallocatable components
>> that have a finalizer. However it triggered also on pointer components
>> with a finalizer. Fixing this makes the ICE go away.
>>
>> The patch regtests cleanly on x86_64-linux-gnu. Ok for trunk?
>>
>> Cheers,
>> Janus
>>
>>
>> 2016-12-08 Janus Weil <[email protected]>
>>
>> PR fortran/61767
>> * class.c (has_finalizer_component): Fix this function to detect only
>> non-pointer non-allocatable components which have a finalizer.
>>
>> 2016-12-08 Janus Weil <[email protected]>
>>
>> PR fortran/61767
>> * gfortran.dg/finalize_31.f90: New test.
>
>
> --
> Andre Vehreschild * Email: vehre ad gmx dot de
! { dg-do run }
!
! PR 61767: [OOP] ICE in generate_finalization_wrapper at fortran/class.c:1491
!
! Contributed by <[email protected]>
module Communicator_Form
implicit none
type :: CommunicatorForm
contains
final :: Finalize
end type
type :: MessageTemplate
type ( CommunicatorForm ), pointer :: Communicator
end type
contains
subroutine Finalize ( C )
type ( CommunicatorForm ) :: C
! should not be called
call abort()
end subroutine
end module
program p
use Communicator_Form
implicit none
class ( MessageTemplate ), pointer :: M
allocate(M)
deallocate(M)
end
