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?
