[Bug fortran/57590] New: [OOP] class containers are recycled between symbols more than they should be

[mikael at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57590

            Bug ID: 57590
           Summary: [OOP] class containers are recycled between symbols
                    more than they should be
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mikael at gcc dot gnu.org

This bug was found while trying to fix pr57297.
Related bugs: pr52227, pr51610, pr53951.

We (gfortran developpers) have decided to generate OOP class containers using
gfortran AST:
we generate a (fortran) fake variable of a (fortran) fake type holding the
object's meta data (virtual table, ...) and a pointer to the actual data
("_data"). Then, at translation stage OOP containers are generated as if they
were regular fortran variables.
As a result of this, the attributes and array spec of an entity become that of
the fake variable's type. So we should generate a different class container
type for any combination of rank, attribute, and array spec.  It's not the case
currently, as shown by the following testcase (which doesn't seem invalid as
far as I know).


  type t
  end type t

  type(t) :: b(3), c(5), d(10), e(11)

  call s3(b)
  call s5(c)
  call sa(d)
  call sn(size(e,dim=1), e)

 contains

  subroutine s3(a)
    class(t), dimension(3) :: a
    print *, shape(a)
  end subroutine s3

  subroutine s5(a)
    class(t), dimension(5) :: a
    print *, shape(a)
  end subroutine s5

  subroutine sa(a)
    class(t), dimension(:) :: a
    print *, shape(a)
  end subroutine sa

  subroutine sn(n, a)
    integer :: n
    class(t), dimension(n) :: a
    print *, shape(a)
  end subroutine sn
end


This prints 3 four times, instead of the expected: 3, 5, 10 and 11, because
s3::a's class container is reused for every 'a' dummy argument of 's5', 'sa'
and 'sn'.
Every of the 'a' dummy argument should have its own class container type.
This means that we have to discriminate not only on the array spec type, but
also for AS_EXPLICIT on the bounds, and on the bounds' expressions (in the 'sn'
case).