Some thoughts on PDTs

[Thomas Koenig]

Hi Paul,

> Ahem!
>
>> after Jerry's implementation of DTIO, only PDTs are
>> missing as a major F2003 feature from gfortran.
>>
>
> 2016-08-22  Paul Thomas  <pault@gcc.gnu.org>
>                  Jerry DeLisle  <jvdelisle@gcc.gnu.org>
>
>      PR fortran/48298
>
> I did the most of the front-end and Jerry the library.


I am truly sorry.  I had not really paid attention, and only remembered
Jerry's last e-mails on the subject (apart from my enthusiasm that
DTIO was finally in there :-)

So, many thanks, and I will try to be more careful about who as done
what in the future, and to give credit where credit is due.

> I posted a fix for pointer
> array components but this was met with silence, presumably because gcc
> was in stage 4. My inclination is to extend this fix to all such
> pointer arrays by moving the 'span' variable from a hidden derived
> type field to the array descriptor, thus fixing this problem properly
> once and for always.

I think this is a good approach. It may require some work on the
library side, hopefully restricted to the macros for accessing
the array descriptor.  I hereby volunteer to help on this, if
help should be needed.


>> We would probably have to extend gfc_symbol with a list of type
>> parameters, including defaults. During resolution, we could then
>> instantiate the new type.  This sound doable in principle (but I am sure
>>  that there are quite a few traps and pitfalls). This would work
>> for a static variable.
>>
>> Things will get more interesting for an allocatable or pointer
>> variable or  dummy argument which is a PDT.
>>
>> Apparently, the kind number has to be a constant expression, which
>> makes things a bit easier.
>
> Funnily enough, it is the kind parameters that make life rather more
> difficult, since derived types have to be instantiated for every
> combination of kind parameters that arise in compilation. Of course,
> these derived types can be "hidden" and their names used to drive the
> instantiation process.


> Thus, for your example below, k1=4 and k2=8 might generate a derived
> type with name _foo_4_8. Instantiation then might proceed along the
> lines:
>
> generate PDT name from variable declaration
> look for PDT in symtree
> if it exists
>   use it
> else
>   generate new smbol and use that
>
> Length parameters are rather easier. The 'users' of these parameters,
> such as the arrays 'a' and 'b' below can be handled as if they are
> allocatable and they can be initialised/finalised using the deferred
> variable mechanism in trans-decl.c

I have also thought a bit along these lines.  We could "simply" make
a PDT into a version of a derived type containing allocatable
arrays or strings, with allocation/deallocation handled by the compiler
or by an explicit ALLOCATE / DEALLOCATE by the user.

The only major problem I see is PDTs in COMMON blocks.  I don't think
they are illegal (well, maybe they should be), but the storage
association rules of COMMON could rule out using ALLOCATABLE
components.

Interestingly enough, ifort has "not yet" implemented
PDTs in COMMON. Of course, we might want to decide that
we don't want to do this, or decide that an implementation
using ALLOCATABLE is good enough, and close any bug reports
which might arise as WONTFIX.
>
> As you might have gathered, I have been giving this some thought.
> Given that the vendors that have delivered PDTs all say that it was
> the most difficult F2003 feature, most of my thinking as been to look
> for the minimum effort route.

I fully agree.

Regards

	Thomas