https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81827
--- Comment #18 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 2 Mar 2018, pault at gcc dot gnu.org wrote: > 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. Fair enough. I read some original comment in this bug that the recursive initialization is bogus in the first place though, so you say all allocations are actually necessary?
