https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120049
--- Comment #13 from kargls at comcast dot net --- On 5/4/25 16:51, kargls at comcast dot net wrote: > 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. Meant to comment. How a compiler handles C_PTR is, of course, processor-dependent. I haven't gone into the internals, but it seems that gfortran casts through a 'void *'. > 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. More to the point, Fortran 2023 18.2.3.6 C_FUNLOC (X) ... Result Characteristics. Scalar of type C_FUNPTR. % cat a.f90 module foo use iso_c_binding, only : c_ptr, c_funptr end module foo % zmore foo.mod ... (2 'C_funptr' '__iso_c_binding' '' 1 ((DERIVED UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN UNKNOWN 0 0 IS_BIND_C IS_C_INTEROP PRIVATE_COMP) ( (4 'c_address' (INTEGER 8 0 1 0 INTEGER ()) () () () (UNKNOWN-FL UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN UNKNOWN 0 0) PRIVATE ())) PRIVATE ( DERIVED 2 0 1 1 VOID ()) 0 0 () () 0 () () () 2 44 0) 3 'C_ptr' '__iso_c_binding' '' 1 ((DERIVED UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN UNKNOWN 0 0 IS_BIND_C IS_C_INTEROP PRIVATE_COMP) ((5 'c_address' (INTEGER 8 0 1 0 INTEGER ()) () () () (UNKNOWN-FL UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN UNKNOWN 0 0) PRIVATE ())) PRIVATE (DERIVED 3 0 1 1 VOID ()) 0 0 () () 0 () () () 2 42 0) Note, both of these refer to c_address, which is an integer(8) on x86_64. Later, the module contains 29 'c_funptr' '__iso_c_binding' '' 1 ((PROCEDURE UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN UNKNOWN 0 0 FUNCTION GENERIC IS_ISO_C ARRAY_OUTER_DEPENDENCY) () (REAL 4 0 0 0 REAL ()) 0 0 () () 0 () () () 2 44) 30 'c_ptr' '__iso_c_binding' '' 1 ((PROCEDURE UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN UNKNOWN 0 0 FUNCTION GENERIC IS_ISO_C ARRAY_OUTER_DEPENDENCY) () (REAL 4 0 0 0 REAL ()) 0 0 () () 0 () () () 2 42) Fortran being case insensitive suggests there may be a few things lurking with the indirect references to c_iso_binding components.
