Non-constant offsets in parametrized derived types?

1

Hello,

By following other threads, I’ve tried the following code for parametrized derived type (PDT). It gives the expected result for the arr component for both gfortran, ifort, and ifx, but the location of arr does not seem to have constant offsets on memory in the case of ifort and ifx (between v(1) and v(2); please see dloc and ddloc). Are constant offsets not guaranteed for such array components, or am I using PDT or loc() etc incorrectly?

program main
    implicit none
    type Foo(n)
        integer, len :: n
        integer :: arr(n)
    end type
    type(Foo(:)), allocatable :: v(:)
    
    integer :: i
    character(*), parameter :: fmt = "(a,*(i0,1x))"

    !! v = [( Foo(2)([10,20]), i=1,5 )]      !! for ifort
    v = [( Foo(2,[10,20]), i=1,5 )]        !! for gfortran
    
    print fmt, "n      = ", ( v(i)% n, i=1,size(v) )
    print fmt, "arr    = ", ( v(i)% arr, i=1,size(v) )
    print fmt, "loc    = ", ( loc(v(i)% arr), i=1,size(v) )
    print fmt, "dloc   = ", ( loc(v(i)% arr) - loc(v(1)% arr), i=1,size(v) )
    print fmt, "ddloc  = ", ( loc(v(i)% arr) - loc(v(i-1)% arr), i=2,size(v) )
    print fmt, "sizeof = ", sizeof(v(1)), sizeof(v)
end

CompilerExplorer + gfortran-13

n      = 2 2 2 2 2
arr    = 10 20 10 20 10 20 10 20 10 20
loc    = 20818352 20818384 20818416 20818448 20818480
dloc   = 0 32 64 96 128   <-- constant offsets
ddloc  = 32 32 32 32
sizeof = 72 360

CompilerExplorer + ifort2021.9

n      = 2 2 2 2 2
arr    = 10 20 10 20 10 20 10 20 10 20
loc    = 25347648 25347744 25347808 25347872 25347936
dloc   = 0 96 160 224 288
ddloc  = 96 64 64 64   <-- why 96 only between v(1) and v(2)?
sizeof = 160 800

CompilerExplorer + ifx2023.1

n      = 2 2 2 2 2
arr    = 10 20 10 20 10 20 10 20 10 20
loc    = 22230592 22230688 22230752 22230816 22230880
dloc   = 0 96 160 224 288
ddloc  = 96 64 64 64   <-- why 96?
sizeof = 160 800
2

Nothing that you will find anywhere, not in the standard for example, that stipulates such offsets. The processor (compiler) does appear to have the leeway to design the type as it suits fit.

Perhaps @greenrongreen will elaborate on Intel’s type design but Intel Fortran does prove rather inefficient for certain AoSoA data structures involving PDTs and that has roots in what can be noticed here, so much so that users have no recourse but to stick with type components of ALLOCATABLE attribute.

1 Like