https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91648
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |burnus at gcc dot gnu.org
--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> ---
During resolution, one has the call tree:
gfc_resolve (ns) -> resolve_types -> gfc_traverse_ns (ns, resolve_symbol) ->
resolve_fl_derived -> gfc_resolve_finalizers
And generate_finalization_wrapper assumes that:
gcc_assert (fini->proc_tree); /* Should have been set in
gfc_resolve_finalizers. */
However, for the test case, one has:
#0 generate_finalization_wrapper (vtab_final=<optimized out>,
vtab_final=<optimized out>, tname=0x7fffffffd450 "m_T", ns=<optimized out>,
derived=<optimized out>) at ../../repos/gcc/gcc/fortran/class.c:2009
#1 gfc_find_derived_vtab (derived=<optimized out>) at
../../repos/gcc/gcc/fortran/class.c:2487
#2 0x0000000000836611 in gfc_find_vtab (ts=0x24f98d8) at
../../repos/gcc/gcc/fortran/class.c:2865
#3 0x0000000000885de3 in gfc_match_assignment () at
../../repos/gcc/gcc/fortran/match.c:1375
Namely, generate_finalization_wrapper is already called during parsing.
Side note: "s" is called recursively – without being marked 'recursive'.
Additionally, at the end of 's', s(y) is called, which calls s(y) etc. –
something which will never finish ...
Better variant – same ICE but avoids this problem:
module m
type t
contains
final :: s
end type
contains
subroutine g(x)
type(t) :: x
class(*), allocatable :: y
y = x
end
subroutine s(x)
type(t) :: x
end
end
