[Patch, fortran] PR46897 - [OOP] type-bound defined ASSIGNMENT(=) not used for derived type component in intrinsic assign
Paul Richard Thomas
paul.richard.thomas@gmail.com
Tue Aug 14 05:04:00 GMT 2012
Dear Mikael,
> I think there are a couple of bugs not triggered by the single component
> types in the test. See below.
Yes, you are right. We should have tested multiple components... my fault!
> This could be moved to the only next caller (`previous' doesn't need to
> be updated if `this_code' is removed) to fix one usage of `this_code' :-).
That's right... I'll make it so.
> ... but I have the feeling that this makes (*code) unreachable and that
> that's wrong. Shouldn't it be "root->next = *code;" ?
No. That caused the regression that I mentioned. (*code) is
resolved, at entry. resolve_code steps on to (*code)->next.
> if we do it after the typebound calls, we overwrite their job so we have
> to do it before.
This is what is done.
> However, if we do it before, we also overwrite components to be assigned
> with a typebound call, and this can have some side effects as the LHS's
> argument can be INTENT(INOUT).
This might be so but it is what the standard dictates should
happen.... isn't it?
Thanks for the review. I believe, in summary, that I should handle
'this_code' consistently so that multiple component defined
assignments work correctly. I should also verify that pointers do
what they are supposed to do, although it is rather trivial.
Cheers
Paul
More information about the Fortran
mailing list