Re: [Patch, fortran] PR46897 - [OOP] type-bound defined ASSIGNMENT(=) not used for derived type component in intrinsic assign

[Mikael Morin <mikael dot morin at sfr dot fr>]

Hello Paul,

I think there are a couple of bugs not triggered by the single component
types in the test. See below.

On 13/08/2012 15:37, Paul Richard Thomas wrote:
> + 
> +       /* Go through the code chain eliminating all but calls to
> + 	 typebound procedures. Since we have been through
> + 	 resolve_typebound_subroutine. */
> +       for (; this_code; this_code = this_code->next)
> + 	{
> + 	  if (this_code->op == EXEC_ASSIGN_CALL)
> + 	    {
> + 	      gfc_symbol *fsym = this_code->symtree->n.sym->formal->sym;
> + 	      /* Check that there is a defined assignment.  If so, then
> + 	         resolve the call.  */
> + 	      if (fsym->ts.type == BT_CLASS
> + 		  && CLASS_DATA (fsym)->ts.u.derived->f2k_derived
> + 		  && CLASS_DATA (fsym)->ts.u.derived->f2k_derived
> + 			->tb_op[INTRINSIC_ASSIGN])
> + 		{
> + 		  resolve_call (this_code);
> + 		  goto next;
> + 		}
> + 	    }
> + 
> + 	  next = this_code->next;
> + 	  if (this_code == root)
> + 	    root = next;
> + 	  else
> + 	    previous->next = next;
> + 
> + 	  next = this_code;
> + 	  next->next = NULL;
> + 	  gfc_free_statements (next);
This frees `this_code', but `this_code' is used to iterate the loop and
below.

> + 	next:
> + 	  previous = this_code;
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' :-).

> + 	}
> + 
> +       /* Now attach the remaining code chain to the input code. Step on
> + 	 to the end of the new code since resolution is complete.  */
This tells me that you know what you do...

> +       if (root)
> + 	{
> + 	  next = (*code)->next;
> + 	  (*code)->next = root;
> + 	  for (;root; root = root->next)
> + 	    if (!root->next)
> + 	      break;
> + 	  root->next = next;
> + 	  *code = root;
> + 	}
... but I have the feeling that this makes (*code) unreachable and that
that's wrong. Shouldn't it be "root->next = *code;" ?
Maybe you want to remove (*code) at the first iteration (as it contains
the whole structure assignment), but in the next iteration, it contains
the first typebound call, etc, doesn't it?

By the way I'm not sure we can keep the whole structure assignment to
handle default assignment:
if we do it after the typebound calls, we overwrite their job so we have
to do it before.
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).

Thoughts?
Mikael