This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, fortran] PR46897 - [OOP] type-bound defined ASSIGNMENT(=) not used for derived type component in intrinsic assign
Dear Paul,
Dear all,
I tried to compile the check_compiler_for_memory_leaks.F90 file
provided by Damian and it produces a segfault error. May be the
problem is related with add_comp_ref.
Regards
Alessandro (from Malta)
2012/8/14 Paul Richard Thomas <paul.richard.thomas@gmail.com>
>
> 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
--
Dott. Alessandro Fanfarillo
Verificatore Ellisse
Cell: 339/2428012
Email: alessandro.fanfarillo@gmail.com