https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120049
--- Comment #12 from kargls at comcast dot net --- (In reply to Jerry DeLisle from comment #11) > (In reply to kargls from comment #8) > > 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) > > > Isn't c_loc(val) an address and therefore not a c_ptr and not a c_funptr? F2023 18.2.3.7 C_LOC (X) ... Result Characteristics. Scalar of type C_PTR. C_PTR is an oblique type. F2023 has C_PTR and C_FUNPTR shall be derived types with only private components. No direct component of either of these types is allocatable or a pointer. C_PTR is interoperable with any C object pointer type. C_FUNPTR is interoperable with any C function pointer type. I brought up c_funptr because I suspect that if one tries to indirectly access c_funptr from a user module instead of directly from the iso_c_binding module, then the need information is not in the user module.
