https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120049
--- Comment #8 from kargls at comcast dot net ---
(In reply to Jerry DeLisle from comment #7)
> That is exactly the patch I was testing Steve.
I assume that you've found that you'll need to
deal with both c_ptr_1 and c_ptr_2. With the
short-circuit for c_ptr_2 in place, this
program tests_gtk_sup
use gtk_sup
implicit none
type(c_ptr), target :: val
print *, c_associated(val, c_loc(val))
print *, c_associated(c_loc(val), val)
end program tests_gtk_sup
fails with
% gfcx -o y g.f90 -fdump-tree-original && ./y
g.f90:10:25:
10 | print *, c_associated(c_loc(val), val)
| 1
Error: Argument C_PTR_1 at (1) to C_ASSOCIATED shall have the type TYPE(C_PTR)
or TYPE(C_FUNPTR)
IIRC, a subroutine has BT_VOID. We should expand the
conditional to also check that we have a function.
if (c_ptr_2.expr_type == EXPR_FUNCTION && c_ptr_2->ts.type == BT_VOID)
return true;
We could be extra careful, and look at
(gdb) p c_ptr_2->value.function->isym.id
$8 = GFC_ISYM_C_LOC
BTW, a similar issue may exist for c_funloc, which returns a c_funptr.
I haven't checked it, yet.
