[Bug fortran/55765] New: Remaining issues with unlimited polymorphic (CLASS(*))

["burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

             Bug #: 55765
           Summary: Remaining issues with unlimited polymorphic (CLASS(*))
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org
                CC: pault@gcc.gnu.org
        Depends on: 55763


Issues related to CLASS(*)

- Smaller bugs, cf. PR 55763


- As mentioned in the submittal email,
http://gcc.gnu.org/ml/fortran/2012-12/msg00090.html

> Some parts of the code, relating to the handling of intrinsic
> expressions, are near duplicates of exiting code for derived types;
> for example class.c( gfc_find_intrinsic_vtab).  I did this in order to
> maximise the separation of the treatment of unlimited polymorphism
> from existing code in the compiler in order that the risk of
> regression be minimised.  This new code can be absorbed later on; eg.
> gfc_find_intrinsic_vtab into gfc_find_derived_vtab.



- CLASS(*) currently doesn't handle nonconstant strings. Currently, for each
string a new __vtab is generated which encodes the string length. The proper
way is to store the information in the variable itself. There are two
possibilities: (a) Either extend the class container to store this information
(b) Use an array descriptor or similar to store this information

(b) requires the new array descriptor and is in line of TR 29113:2012, where at
least for strings the full array descriptor is passed (with BIND(C)), cf.
ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1942.pdf  See 8.7, (6) (b) and (c) and
8.3 - in particular "size_t elem_len" which together with the type (char(kind=1
or 4)) can be used to determine the length.

(a) requires an additional field in the class container. In principle, it could
come last, but that will prevent the extension of the rank. Currently, one has
{ _data, _vtpr } and for assumed-rank, one passes a max-rank (rank-7) array to
make sure the offset to _vptr is correct. With {_vptr, _data}, the last item
could remain the actual size; but with {_vptr, _data, int string_len } that
won't work. Cf. PR 53971.