Sum and MaxVal returning incorrect values

The following code defines a derived type, t2, in terms of another derived type, t1. If an array of type t2 is allocated and values assigned, the intrinsic functions Sum and MaxVal return incorrect values (and my guess is that MinVal and possibly some other functions will have similar problems).

Module m
   Type t1
      Integer :: n
      Real :: r
   End Type t1
   Type t2
      Type(t1) :: tt
   End Type t2
!
   Type(t2), Dimension(:), Allocatable :: at2
End Module m


Program p
   Use m, Only: at2
   Integer :: n = 5
   Integer :: i
!
   Allocate (at2(n))
   Do i = 1, n
      at2(i)%tt%r = 99.0
      at2(i)%tt%n = 2
   End Do
   Print*, at2(:)%tt%n
   Print*, MaxVal(at2(:)%tt%n)
   Print*, Sum(at2(:)%tt%n)
End Program p

One of the truly wonderful things about being an old dog (i.e. unable to learn new tricks) is that one rarely gets caught out by such things!

I'm a firm believer that everything should work as it is supposed to, or there ought to be documentation to the effect that something doesn't work, so no doubt one of Paul's 'I have made a note of this' remarks means that it will soon be fixed. I hope so, as there's zero chance of it going into the help file!

Eddie

Simon

Thank you for the feedback. This appears to be an orginal bug. I have logged it for investigation.

Perhaps I am suffering from too much lockdown (now predicted to go to November!!), but why use the following structure ?

at2(i)%tt%r = 99.0

I know it is possible in Fortran syntax, but doesn't the following approach achieve the same result ?

at2_tt(i)%r = 99.0

I do not appreciate the need for heiracthical derived types. I do have extensive use of derived types for data structures to define problems, but then tend to use multi-dimension arrays and vectors for the compute intense phase. Then again, most FE calculations are simply F = K . X.

John, in Simon's example Type t2 contains only one member, namely, tt, which is what you probably see as rather pointless. On the other hand, the test code shown may have been obtained by paring down production code. For example, the production code could well have had the declaration

   Type t2
      Type(t1) :: tt
      Character(len=2) :: cc  ! 2-character country code
   End Type t2

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

As always, Paul has responded quickly and completely to an error report, which is at least one of the reasons why FTN95 is so valued by its users. I'm always impressed by that, even if I will never use the facility.

E

Yes, thanks very much Paul. And mecej4 is correct - I have paired the code down to the minimum required to reproduce the error. There is no attempt to make the example look like a worthwhile use of derived types; the intent was only to make Paul's job as simple as possible. For what it's worth, the original code is something like the following, with Type(area) defining an area bounded by latitude and longitude limits, and Type(domain) containing additional information to define the size of the area and locate it in a larger field:

! - area -
   Public :: area
   Type area
      Sequence
      Real(Kind=rp) :: rltn ! - northern area limit -
      Real(Kind=rp) :: rlts ! - southern area limit -
      Real(Kind=rp) :: rlgw ! - western area limit -
      Real(Kind=rp) :: rlge ! - eastern area limit -
   End Type area
!
! - domain -
   Public :: domain
   Type domain
      Sequence
      Integer :: nlts    ! - number of latitudes in domain -
      Integer :: nlgs    ! - number of longitudes in domain -
      Integer :: ilt1    ! - northern latitude domain limit index -
      Integer :: ilt2    ! - southern latitude domain limit index -
      Integer :: ilg1    ! - western longitude domain limit index -
      Integer :: ilg2    ! - eastern longitude domain limit index -
      Type(area) :: alim ! - area limits -
   End Type domain