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

[Tobias Burnus <burnus at net-b dot de>]

Janus Weil wrote:
> 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.

I am not completely sure what you get with your patch, but if this%foo_x 
has the value "42" then also product%foo_x should have the value 42 
after executing
     allocate (product, source = this)

Tobias