Re: [RFC] Polymorphic deep copy (aka PR46174)

[Janus Weil <janus at gcc dot gnu dot org>]

Hi Tobias,

> Regarding the generate code, I have a RFC: Currently, gfortran assume that
> all code is old and uses no polymorphic data types. Only few newer code
> exists which does. A consequence of that is that the vtable is always
> populated per translation unit. For instance, the "copy$<dt_name>" exists in
> every file which uses CLASS(t).(As function which is not externally
> visible.) That works and is fine; however, if one has a program which
> heavily uses polymorphic types, the size could be significantly reduced by
> generating the function only once at the place where the TYPE is defined.

well, actually it's not that bad. One has to distinguish two cases:

1) The module where the derived type is defined contains polymorphic
code. Then the vtab symbol is generated already in this base module,
and is use-associated by all other modules using the type, which means
we only have one unique instance of the vtab.

2) The module where the derived type is defined does *not* contain
polymorphic code. Then we generate no vtab symbol for the type in the
base module, and every other module using the derived type
(polymorphically) will generate it's own vtab (i.e. we can have
several instances).

I would regard case #1 as the standard case for real polymorphic code
(e.g. as soon as your module includes TBPs with 'pass'-arguments, the
vtab is being created in the base module), and for this case we are
doing fine and don't generate duplicate vtabs. The second case is more
problematic, but it is also more rare I think. Therefore I'd say our
approach is good for the most common usage scenarios. Also I don't
know how to do it better (without clobbering non-OOP programs with
vtabs).


>> The attached new version of the patch finally is free of regressions
>> (on x86_64-unknown-linux-gnu). Ok for trunk?
>
> OK; but please add (or "dg-do run" enable) a test case for the user-defined
> assignment.
>
> You could also add PR 45451 to the changelog as the patch seemingly fixes
> the last remaining issue of that PR.

Thanks for the review. I'll make the changes you propose and commit tonight.

Cheers,
Janus