probably this can do: transfer( c_loc(x), 0_c_intptr_t)
Here is an example of using the C interop facilties
include ‘integer_kind_module.f90’
program ch1808
use iso_c_binding
use integer_kind_module
implicit none
integer, pointer :: a => null(), b => null()
integer, target :: c
integer, target :: d
type (c_ptr) :: x
integer (i64) :: x_address
c = 1
a => c
c = 2
b => c
d = a + b
print *, a, b, c, d
x = c_loc(a)
x_address = transfer(x,x_address)
print *,x_address
x = c_loc(b)
x_address = transfer(x,x_address)
print *,x_address
x = c_loc(c)
x_address = transfer(x,x_address)
print *,x_address
x = c_loc(d)
x_address = transfer(x,x_address)
print *,x_address
end program
I finally read through the f2023 sections on equivalence and common block storage association. It says that the default kind numeric logical, integer, real, and complex scalars and arrays behave as they did in f77, but only storage association between entities of the same types and kinds are allowed for nondefault kinds. Storage association with nondefault kinds would be an extension and not covered by the standard. Padding is mentioned in various places in the discussion, so the standard is written in a way to allow maximum flexibility to compilers in that respect.
So to give an example, a nondefault int64 integer array that is storage associated with a default complex array might or might not have the array elements aligned as one might expect because the int64 array might have padding inserted, while a complex array and a double precision array would still align as described in the f77 standard. If a programmer does have such arrays associated, as an extension of the standard, then the programmer would need to test for the correct alignment using the c_loc() and/or storage_size() intrinsics.