[RFC] Polymorphic deep copy (aka PR46174)

[Janus Weil]

>> Also I have weeded out a couple of regressions and am left with only a
>> single one: class_defined_operator_1.f03 aborts at run-time. It has
>> several abort()'s and fails already at the first one, where the result
>> is now -42 instead of +42.
>>
>> The reason for this is that the "ALLOCATE with SOURCE" statement now
>> makes use of the defined assignment operator for copying the source,
>> which introduces the additional minus sign. I am not completely sure
>> if this behavior is ok and was not able to pinpoint it in the standard
>> so far. Can anyone tell me if ALLOCATE w/ SOURCE is actually supposed
>> to use the defined OPERATOR(=) or not?
>
> "On successful allocation, if allocate-object and source-expr have the same
> rank the value of allocate-object becomes that of source-expr, otherwise the
> value of each element of allocate-object becomes that of source-expr."
> (F2008, 6.7.1.2)
>
> Thus, ALLOCATE with SOURCE= acts in the same way as an intrinsic assignment
> or a deep-copying memcpy would do. The (unmodified!) test case also succeeds
> with crayftn.

Well, ok.

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.

Regtesting now. Ok for trunk if successful? (with a ChangeLog and test
case of course)

Btw, I also verified that the patch fixes Salvatore's original test
case in PR 45451.

Cheers,
Janus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr46174_copy_v2.diff
Type: application/octet-stream
Size: 10132 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20101105/72eb9095/attachment.obj>