On Tue, Dec 17, 2024 at 20:05 Steve Kargl <s...@troutmask.apl.washington.edu> wrote:
> On Mon, Dec 16, 2024 at 04:53:42AM -0800, Or, perhaps, you care to qualify your generalization? Thanks for asking. When I tried using kind type parameters on derived types with gfortran a few months ago, I gave up because the issues appeared to be so fundamental that I couldn’t even find workarounds that would allow me to use the feature at all while awaiting patches. I corresponded with Paul, who did the initial implementation of parameterized derives. I hope Paul is ok with me quoting his description of the overall situation about 2 months ago. Paul’s assessment is below. Also, I believe Andre is planning to work on PDT support sometime next year. Damian — snip — The most significant change that is required comes about from PR82649. While kludges exist, the best approach is to completely change the PDT representation, which is generated in decl.cc(gfc_get_pdt_instance). My plan was to represent a PDT instance by a container: type(pdt_instance) type(pdt_data), dimension(gfc_max_dimensions), pointer :: data integer, kind :: param1 ... integer, len :: paramN ... end type Of course, this change will result in a huge amount of downstream fallout in resolve.cc and trans*.cc. Grepping "attr.pdt" will reveal the affected files. The present representation for *each element* is: type(pdt_instance) integer, kind :: param1 ... integer, len :: paramN ... data_components end type A possible alternative approach would be to add a "hidden" field, _allocated and to leave a single element with the parameter fields retaining their values after deallocation.
