https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87127
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> ---
Variant:
program test
implicit none
integer :: exfunc, i
call foo()
contains
subroutine foo()
write(*,*) exfunc(i)
end subroutine foo
end program
In primary.c's gfc_match_rvalue(), we try to parse a symbol in several ways –
if everything fails:
/* Give up, assume we have a function. */
gfc_get_sym_tree (name, NULL, &symtree, false); /* Can't fail */
sym = symtree->n.sym;
e->expr_type = EXPR_FUNCTION;
if (!sym->attr.function
&& !gfc_add_function (&sym->attr, sym->name, NULL))
This sets both attr.flavor = FL_PROCEDURE and attr.function = 1.
If we call "exfunc" in "program test", everything is fine.
However, if we call "exfunc" in a block (associate) or a contained procedure,
we are in a different namespace.
In the local namespace, the symbol is FL_PROCEDURE with attr.function.
In the parent namespace, the symbol has will be to FL_VARIABLE.
In resolve_symbol, one tries to resolve the symbol:
if (sym->attr.flavor == FL_UNKNOWN
|| (sym->attr.flavor == FL_PROCEDURE && !sym->attr.intrinsic
&& !sym->attr.generic && !sym->attr.external
&& sym->attr.if_source == IFSRC_UNKNOWN
&& sym->ts.type == BT_UNKNOWN))
{
Thus, one ends up with a symbol without attr.function.
