Lbound with derived-type arrays

I would have expected the following program to print 0 and 2, but FTN95 and at least two other compilers return 1 and 3. The program is trying to print the lower bound of an array within a derived type, when the lower bound is explicitly defined as 0. Please advise how my understanding is incorrect.

Module m
   Type t
      Integer, Dimension(0:2) :: i
   End Type t
   Type(t), Dimension(3) :: at
End Module m
!
Program p
   Use m
   Print*, lbound(at(1)%i(:)), ubound(at(1)%i(:))
End Program p

You may find the answer if you replace (0:2) by (-2:0) in the definition of t%i and see how that changes the results.

Changing the Print statement to

Print*, lbound(at(1)%i), ubound(at(1)%i)

and seeing the effect on the output may throw more light on the issue.

Thanks for the response. Indeed, the same output. The lower bound becomes 1 regardless of the definition. So effectively, you cannot use different bounds in a derived-type array?

Use the whole array...

   Print*, lbound(at(1)%i), ubound(at(1)%i)

Hmm, that is curious. What actually is the difference between at(1)%i and at(1)%(:), or, for that matter, between, say, iarray and iarray(:)?

The colon usually denotes an array section, a sub-array which is a copy of part of the whole. Presumably the copy can be of the whole but is a different object with, in this context, different properties.

I think I get that. But what about the following? Surely this code should return 2 rather than 3. And it returns 3 even if you delete (:) in the Print statement

Module m
   Type t1
      Integer, Dimension(3) :: i
   End Type t1
   Type t2
      Type(t1) :: t
   End Type t2
   Type(t2), Dimension(2) :: at2
End Module m
!
Program p
   Use m
   Print*, Size(at2(:)%t%i(1))
End Program p

Simon

It looks like FTN95 is giving an incorrect result in this context. I will log this for investigation.

Hi Paul, Any progress on this one? I have work-arounds, but I have quite a few instances that I think are equivalent, where I am passing an array of a derived type, and the routine does not get what I would expect. For example,

Call s ( at2(:)%t%i(1) )

Simon

This failure has not yet been fixed. An initial investigation located the point of failure but not the fix.

At first sight it's not obvious to me what you are asking for in the call to s(at2(:)%t%i(1)), which is some kind of 'copy-in' of components extracted from the data structure.

Sometimes it is better to simplify the logic of the coding.

Simon

If Call s(at2(:)%t%i(1)) does not do what you expect then can you provide sample code that illustrates what you get and what you expect.

It could easily be a different issue.

Hi Paul, The following example does not quite reproduce the error I have in mind, but it is outputting a surplus value (which is presumably because the size of ia in subroutine s is still in error):

Module m
   Type t1
      Integer, Dimension(3) :: i
   End Type t1
   Type t2
      Type(t1) :: t
   End Type t2
   Type(t2), Dimension(2) :: at2
 Contains
  Subroutine s (ia)
   Integer, Dimension(:), Intent(In) :: ia
   Print *, ia
  End Subroutine s
End Module m
!
Program p
   Use m
   at2(1)%t%i(:) = [ 11, 12, 13 ]
   at2(2)%t%i(:) = [ 21, 22, 23 ]
   Call s ( at2(:)%t%i(2) )
End Program p

Simon

Thanks. I have logged this for investigation.

This failure has now been fixed for the next release of FTN95.