https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83076
--- Comment #4 from Paul Thomas <pault at gcc dot gnu.org> --- (In reply to Paul Thomas from comment #3) > Yes, indeed it was the main part of my patch. I cannot see at the moment, > though, why forcing the creation of a vtable is having this effect on caf in > deallocate. > > The call to gfc_caf_attr at trans-stmt.c:6644 is detecting that the > component does not have attr.coarray_comp set so that is_coarray_array does > not get set a few lines later and the wrong branch is taken at line 6661. > Setting the latter flag in gdb at line 6651 allows the compilation to > complete successfully. > > Why a call to gfc_find_derived_vtab should have this effect is not evident > to me at the moment. I'll take it though. > > Thanks for the heads up, Jakub. > > Paul When I revert the patch for pr81447 (r254427) the testcase here compiles. However, adding a class declaration triggers the same problem: module m type t integer, pointer :: z end type class(t), allocatable :: c ! <= This triggers the same problem. contains function f(x) type(t) :: x[*] if ( associated(x%z) ) deallocate(x%z) end end Hence, I would say that it is a pre-existing problem that has been exposed by the fix for r254427 and is not really a regression. Paul