Hi Andre, > yes, that was what I had in mind for the testcase. Now it looks ok to me.
thanks for reviewing, committed as r243483. Cheers, Janus > On Thu, 8 Dec 2016 16:41:23 +0100 > Janus Weil <ja...@gcc.gnu.org> wrote: > >> 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 <ja...@gcc.gnu.org> 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 <ja...@gcc.gnu.org> >> >> >> >> 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 <ja...@gcc.gnu.org> >> >> >> >> PR fortran/61767 >> >> * gfortran.dg/finalize_31.f90: New test. >> > >> > >> > -- >> > Andre Vehreschild * Email: vehre ad gmx dot de > > > -- > Andre Vehreschild * Email: vehre ad gmx dot de
