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

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

>> I think the problem was the following: The assigment in copy$foo, which is
>> just
>> ? dst = src ? ? ?!!! both 'dst' and 'src' being TYPE(foo)
>> was falsely transformed into a call to the typebound assignment
>> operator, although no polymorphic pass-object was present. I fixed
>> this by modifying gfc_extend_assign in interface.c.
>
> I am not 100% sure about the code in gfc_extend_assign. In particular, I
> wonder whether
>
> ?if (lhs->ts.type == BT_CLASS)
> ? ?{
>
> should not also have "|| lhs->ts.type == BT_TYPE". Though, that probably
> would just undo what you did in the patch.
>
> I think the following program is valid and now rejected with your patch:

Of course you're right. I was on the wrong track here.

So I removed this piece again and instead marked the namespace of
'copy$...' as resolved, which prevents the intrinsic assign from being
replaced during resolution.

The attached new version of the patch finally is free of regressions
(on x86_64-unknown-linux-gnu). Ok for trunk?

Cheers,
Janus


2010-11-05  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/46174
	* class.c (gfc_find_derived_vtab): Improved search for existing vtab.
	Add component '$copy' to vtype symbol for polymorphic deep copying.
	* expr.c (gfc_check_pointer_assign): Make sure the vtab is generated
	during resolution stage.
	* resolve.c (resolve_codes): Don't resolve code if namespace is already
	resolved.
	* trans-stmt.c (gfc_trans_allocate): Call '$copy' procedure for
	polymorphic ALLOCATE statements with SOURCE.

2010-11-05  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/46174
	* gfortran.dg/class_19.f03: Modified.
	* gfortran.dg/class_allocate_6.f03: New.

Attachment: pr46174_copy_v3.diff
Description: Binary data

Attachment: class_allocate_6.f03
Description: Binary data