"FX" <coudert@[EMAIL PROTECTED]
> wrote in message
news:fuf742$1j7j$1@[EMAIL PROTECTED]
>> type, bind(C) :: descr
>> type(C_PTR) address
>> integer(C_INTPTR_T) unknown1
>> integer(C_INTPTR_T) unknown2
>> integer(C_INTPTR_T) stride
>> integer(C_INTPTR_T) unknown3
>> integer(C_INTPTR_T) last_element
>> end type descr
> No, these are not the types I indicated.
I know. These are what I came up with via reverse engineering
gfortran assembly language output. Given do***entation instead I
would be more inclined towards:
use ISO_C_BINDING, only: C_PTR, C_SIZE_T
type, bind(C) :: descriptor_dimension
integer(C_SIZE_T) stride
integer(C_SIZE_T) lbound
integer(C_SIZE_T) ubound
end type descriptor_dimension
type, bind(C) :: descriptor_1
type(C_PTR) data
integer(C_SIZE_T) offset
integer(C_SIZE_T) dtype
type(descriptor_dimension) dim(1)
end type descriptor_1
The first kind type that I noticed changed from 32 to 64 bits
on going from 32-bit Windows to 64-bit Windows was C_INTPTR_T,
quite analogous to DVF/CVF/ifort int_ptr_kind(). I guess
size_t does the same thing and ssize_t follows along for the
ride which is why all the descriptor fields ended up being
64 bits wide. It's hard to tell how they got that way from
reverse engineering alone.
>> So it seems that the structure constructor for type(descr) isn't
>> assigning that first member, address.
> I got to the following reduced testcase:
[snip]
> $ gfortran a.f90 && ./a.out
> 0 -1073744200
> where both gfortran and g95 give weird results (Sun doesn't want to
> compile it, for some reason I don't understand).
Thanks for taking a look at this. I try to keep you informed when
I find this kind of behavior.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
|
