(Follow up from 41777, comment 10)
The following variable_check in check.c does not make much sense:
if ((e->expr_type == EXPR_VARIABLE
&& e->symtree->n.sym->attr.flavor != FL_PARAMETER)
|| (e->expr_type == EXPR_FUNCTION
&& e->symtree->n.sym->result == e->symtree->n.sym))
return SUCCESS;
I think the idea is to support
function f()
f = 4.0
end function f
where this "f" is to regarded as variable. However, the test is also called
outside of the function body of "f" (incl. internal procedures of f). In that
case it does not make much sense.
The following example shows this: For LOC(f) it prints the address of the
function, for LOC(f()) the result of the function call; but it fails for
LOC(g()) due to
e->symtree->n.sym->result == e->symtree->n.sym
(Ditto if "f" had a result variable.)
* * *
I think the proper fix would be
a) To check whether is in the function body of "f" (incl. internal procedures
of f) - and return FAILURE otherwise.
b) Optionally: Also allow LOC() for function (i.e. pointer address of the
function itself). Supporting LOC(f()) does not make much sense, except for
debugging - if one allows the latter, one also needs to handle generic
functions.
* * *
module m
interface g
module procedure f
end interface g
contains
function f()
integer, pointer :: f
f => null()
end function f
end module m
use m
print *, loc(f) ! prints something like 4196132
print *, loc(f()) ! print 0
print *, loc(g()) ! Error: must be a variable
end
--
Summary: Bogus variable_check
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42934
