https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81827
--- Comment #16 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #15)
> Bisected to pauls r254427, the fix for PR81447 and PR82783.
>
> Test adjustments suggest that we'll create even more malloc/free calls.
Hi Richard,
I am sorry to take so long to get back to this.
The vtable copy and finalise procedures get expanded for the allocatable
components to the the ultimate allocatable components. This is only an issue,
of course, if the vtable is generated.
This also exhibits the problem:
program main
implicit none
type level1
real, allocatable :: var_r1(:), var_r2(:), var_r3(:), var_r4(:),
var_r5(:)
integer, allocatable :: var_i1(:), var_i2(:), var_i3(:), var_i4(:),
var_i5(:)
complex, allocatable :: var_c1(:), var_c2(:), var_c3(:), var_c4(:),
var_c5(:)
logical, allocatable :: and_this_makes_sixteen(:)
end type level1
type level2
type(level1), allocatable :: var1(:), var2(:), var3(:), var4(:),
var5(:)
end type level2
type level3
type(level2), allocatable :: var1(:), var2(:), var3(:), var4(:),
var5(:)
end type level3
type level4
type(level3), allocatable :: var1(:), var2(:), var3(:), var4(:),
var5(:)
end type level4
class (level4), allocatable :: foo(:) ! TYPE (level4) does not exibit the
long compile time.
allocate(foo(1))
end program
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
