Tobias Burnus wrote:
Janus Weil wrote:
yes, the patch looks basically ok to me. Just one thing I did not
quite understand:
+ /* It can happen that the LHS has BT_DERIVED but it is in reality
+ a polymorphic variable. */
How exactly can it happen that a polymorphic variable is BT_DERIVED?
I miss remembered (too hot here!) - the problem wasn't for one of my
newly added test cases but for an existing one. Without that bit, the
following test case is failing:
class_array_12.f03 (and class_array_15.f03):
It fails via gfc_trans_class_assign -> gfc_trans_pointer_assignment:
1075 tmp = gfc_trans_pointer_assignment (expr1, expr2);
Namely for the line
BGet => self%componentB(1)
There:
expr1->ts.type == BT_DERIVED
expr1->symtree->n.sym->ts.type == BT_CLASS
expr1->ref->type == REF_COMPONENT
expr1->ref->u.c.component->name == "_data"
and
expr2->ts.type == BT_CLASS
expr2->ref->type == REF_COMPONENT
expr2->ref->u.c.component->name == "componentb"
expr2->ref->u.c.component->ts.type == BT_CLASS
expr2->ref->next->u.ar.type == AR_ELEMENT
Both is kind of okay, but inconsistent. My newly added code does:
+ if (expr1->ts.type == BT_DERIVED && expr2->ts.type == BT_CLASS
+ && expr2->expr_type != EXPR_FUNCTION)
+ gfc_add_data_component (expr2);
which adds a "_data" ref to expr2 - but expr2->ts.type remains BT_CLASS.
Thus, the code later runs into:
+ if (expr1->ts.type == BT_DERIVED && expr2->ts.type == BT_CLASS
+ /*&& !gfc_is_class_scalar_expr (expr1)*/)
+ rse.expr = gfc_class_data_get (rse.expr);
which fails without the "gfc_is_class_scalar_expr" as one then adds a
"_data" ref to the existing "_data" ref.
I think my changed check is bogus (even if it solved the problem) and
the real problem is that gfc_add_data_component doesn't update
expr->ts.type to BT_DERIVED. - I will try that - and see what else will
break.
Tobias
