- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Let's say I have the following:
type a
type(other),dimension(:),allocatable :: def
endtype
type(a),dimension(:),allocatable :: abc
Assume that abc and it's def components are allocated correctly.
If I pass the following as an argument:
abc(1:x)%def(2)
(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
abc(1)%def(2)
abc(2)%def(2)
...
abc(x)%def(2)
This does not seem to work in IVF 15 update 4 (yeah, I know, get the latest version - believe me I'd like to).
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 contains 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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page