This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


>> PR 46174 brought up the necessity of doing a deep copy of polymorphic
>> variables (with allocatable components). Tobias pointed out that the
>> best (only?) way to accomplish this would be to add a new procedure
>> pointer component (named '$copy') to the vtab, which would point to a
>> copying routine for the corresponding type. Polymorphic deallocation
>> could be handled analogously.
>>
>> Attached is a draft patch which does just that: It adds two new PPCs
>> to the vtab ($copy and $free) and sets up the corresponding routines.
>> Looking at the dump for a test case indicates that this seems to work
>> quite nicely already. What does not work yet is the calling of these
>> routines (which means there is something wrong in the hunk in
>> trans-decl.c, which was just a quick try - I'll improve this soon).
>>
>> Two questions:
>> 1) Am I technically on the right track with this patch? Any comments?
>
> No comment on this and I am not the right one to review the patch.
>
>> 2) Is this patch appropriate for whatever stage of development GCC is
>> currently in? [The website still shows "stage 1", while the last
>> status report said stage 1 would end at the end of October.]
>>
> Regarding 2) If this fixes a bug with an existing "feature" it is OK to do
> even after stage 1 is done.

I guess one can argue where to draw the line between "fixing a bug"
and "adding a feature". In this case I would say we already have
"allcoate with SOURCE" as a feature and the patch is fixing a bug on
that feature.

Anyway it seems we are technically still in stage 1.


> The key here is not to do things that are risky
> as we get closer to the end of stage 2. ?Definitely we do our best to avoid
> regressions. Fixing wrong code is definitely a good thing.

I would say this patch is not *too* risky. At least it won't affect
codes which don't use CLASS.

Attached is an updated version of the patch which fixes the original
test case (but is not yet perfect in all details).

Cheers,
Janus

Attachment: pr46174_v2.diff
Description: Binary data


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]