https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81827
--- Comment #17 from Paul Thomas <pault at gcc dot gnu.org> --- > There are two ways to fix this: > (i) Generate incomplete vtables, with the pointers to copy and finalise set > to null, for module derived types. This has the disadvantage that class > objects, such as the above, will still cause the compilation cascade; or > (ii) Call the functions associated with each derived type vtable at each > level. > > My preference would be for the latter and I will set to seeing how it can be > done. > > Cheers > > Paul Hi Richard, I am waiting for a light bulb moment on this problem. The source of the problem lies in the automatic deallocation and copying of allocatable derived type components. This is carried out be the chunk of code trans-array.c:8299-9396. The problem will remain, even if I carry out (i) and (ii) above. Every time that 'foo' in the reporter's testcase is allocated or if it were declared anywhere other than the main programme, the automatic deallocation/finalisation will occur and this will cause the exponential code bloat on each and every occasion. The 'obvious' way to deal with this is to ape the code in trans-array.c with library functions that make use of a reduced representation of the derived types (a list of offsets and pointers to the corresponding derived type component functions, where needed) or generated functions for each derived type. I am afraid that this will not happen overnight. Erik Edelman and I discussed this possibility originally but were put off by the complexity, compared with the present methodology, which has grown like Topsy since. I propose to work on the other regressions/bugs that I have caused and to come back to this for 9.0.0. Paul
