This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, Fortran] PR57530 (Part 2 of 3) Support TYPE => CLASS
- From: Tobias Burnus <burnus at net-b dot de>
- To: Janus Weil <janus at gcc dot gnu dot org>
- Cc: gcc patches <gcc-patches at gcc dot gnu dot org>, gfortran <fortran at gcc dot gnu dot org>
- Date: Sat, 27 Jul 2013 14:18:55 +0200
- Subject: Re: [Patch, Fortran] PR57530 (Part 2 of 3) Support TYPE => CLASS
- References: <51F1A31F dot 3040404 at net-b dot de> <CAKwh3qhS45WkQKMSJp9=QjJ1fhVU4VQK5LG0v-0Vf-r+QMWupg at mail dot gmail dot com> <51F39827 dot 8020607 at net-b dot de>
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