This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] Polymorphic deep copy (aka PR46174)
On 11/05/2010 03:01 PM, Janus Weil wrote:
I think the following program is valid and now rejected with your patch:
Can we add that program or turn one of the type-bound operator test
cases from dg-do compile to dg-do run? Seemingly, we lack such a test case.
* * *
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.
+ No OOP penalty for code which never uses CLASS
+ Local scope which makes inlining even without LTO easier
- Larger files due to duplicated code
+ Generated only once, smaller files
- Also generated if CLASS is not used
Comments? We don't have to decide now, but if we change the ABI, it has
either to be in 4.6 or in the ABI-breaking version (4.7?). 4.6 is OK
because in 4.5 the polymorphism support was very experimental.
See also PR 46313 (part c) for another reason to break the ABI.
* * *
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
You could also add PR 45451 to the changelog as the patch seemingly
fixes the last remaining issue of that PR.
PS: The next step logically following this patch is to add deep-"free$"
support (cf. comment 2 of this PR 46174) and - in relation with
automatic (re)allocation on assignment - to add support for an
assignment to a polymorphic variable.