https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58787
--- Comment #15 from Tobias Burnus <burnus at gcc dot gnu.org> ---
I think the following happens:
1. When the contained procedure is parsed, we print out an error for
"get_proc_name" - but this error is ignored; the symbol is pulled into the
current namespace and sym->refs++ (-> 2; 1 is the use-associated function).
2. We then parse the function argument; this correlates with a
sym->formal_ns (but this is only set during resolution)
as we try to set an attribute, this fails.
3. The statement is rejected, which rolls back the symbol settings.
When the current (= contains) namespace is freed, one calls:
gfc_release_symbol()
which has:
3093 if (sym->formal_ns != NULL && sym->refs == 2 && sym->formal_ns !=
sym->ns
3094 && (!sym->attr.entry || !sym->module))
3095 {
3096 /* As formal_ns contains a reference to sym, delete formal_ns
just
3097 before the deletion of sym. */
where the contained namespace is deleted, sym->ns is the subroutine with the
use-associated symbol and sym->formal_ns is the formal namespace of the
use-associated symbol.
Hence, we now delete the formal namespace of "sym".
Later, when the outer subroutine namespace is resolved, this namespace is
already gone.
