This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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: [Patch, fortran] PR46897 - [OOP] type-bound defined ASSIGNMENT(=) not used for derived type component in intrinsic assign


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


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