Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!

structure slicing question


Let's say I have the following:

type a
   type(other),dimension(:),allocatable :: def
type(a),dimension(:),allocatable :: abc

Assume that abc and it's def components are allocated correctly.

If I pass the following as an argument:


(assuming x is within the allocated size of abc)

Can I expect to receive an dummy argument that meets this declaration:

type(other),dimension(:) :: dum

(assuming an explict interface) that would contain x elements?
i.e. an array of type "other" containing specifically

This does not seem to work in IVF 15 update 4 (yeah, I know, get the latest version - believe me I'd like to).

0 Kudos
2 Replies
Valued Contributor II

Well, there's this thing about

C918 (R911) There shall not be more than one part-ref with nonzero rank. A part-name to the right of a part-ref with nonzero rank shall not have the ALLOCATABLE or POINTER attribute.

I guess that may be the case because that would in general create an array section with variable stride, more like an array section with a vector subscript. The Fortran processor would have to pass the addresses of each element, not just their indices, or maybe do a copy-in copy-out which is in itself problematic in the standard.

Here's something I tried with parameterized derived types:

module M
   implicit none
   type other
      integer key
   end type other
   type a(len)
      integer, len :: len
      type(other) def(len)
   end type a
      subroutine S(dum)
         type(other), dimension(:) :: dum
         write(*,*) dum
      end subroutine S
end module M

program P
   use M
   implicit none
   type(a(:)), allocatable :: abc(:)
   integer i

   allocate(a(len=3) :: abc(4))
   abc(:)%def(2) = [(other(i),i=1,size(abc))]
   call S(abc(:)%def(2))
end program P

But my output with ifort 16.0 was

           1     7340141  1280592212     6881372

Is this a compiler bug?


Black Belt

It goes beyond just complications around a variable stride - such a designator would potentially permit elements of the one array to have different allocation/association status, dynamic type, length parameters, etc.

The issue in #2 is a PDT implementation bug, still present in current beta.  Otherwise type parameters are a good solution for this.