--- Comment #17 from Paul Thomas <pault at gcc dot> ---

> 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

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.


Reply via email to