https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66544
--- Comment #8 from janus at gcc dot gnu.org --- (In reply to janus from comment #4) > Btw, I don't fully understand why "implicit none" should make any difference > here. The problem is that we simply do not know which typespec to give to 'z' (and thus to 'f'), therefore it stays with BT_UNKNOWN which causes the ICE. When omitting the 'implicit none', the symbols get typed implicitly, which is not really correct either. If you believe it's valid, one could hack around the ICE using BT_VOID or so: Index: resolve.c =================================================================== --- resolve.c (revision 243433) +++ resolve.c (working copy) @@ -220,6 +220,8 @@ resolve_procedure_interface (gfc_symbol *sym) sym->attr.class_ok = ifc->result->attr.class_ok; sym->as = gfc_copy_array_spec (ifc->result->as); sym->result = sym; + if (sym->ts.type == BT_UNKNOWN && ifc->result->attr.proc_pointer) + sym->ts.type = BT_VOID; } else { But that's certainly not a very nice and clean solution and I have no idea if it would produce the expected results at runtime. I'm still a bit doubtful if it's really valid. Are there any other compilers which accept such a construct?