Tobias Burnus wrote:
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:
When I remove the "if" in class.c's gfc_add_component_ref's
if (!next)
e->ts = (*tail)->u.c.component->ts;
I get several failures, e.g.:
gfortran.dg/finalize_12.f90
gfortran.dg/finalize_13.f90
gfortran.dg/select_type_26.f03
gfortran.dg/select_type_27.f03
gfortran.dg/class_array_1.f03
gfortran.dg/class_array_15.f03
etc.
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.
Giving up on the class.c version, would be the following change okay?
+ if (expr1->ts.type == BT_DERIVED && expr2->ts.type == BT_CLASS
+ && expr2->expr_type != EXPR_FUNCTION)
+ {
+ gfc_add_data_component (expr2);
+ /* The following is required as gfc_add_data_component doesn't
+ update ts.type if there is a tailing REF_ARRAY. */
+ expr2->ts.type = BT_DERIVED;
+ }
+
[together with the removal of gfc_is_class_scalar_expr:
+ 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);
]
It still feels a bit like a hack - but it is definitely much cleaner
than my previous band aid.
Built and regtested on x86-64-gnu-linux.
OK?
Tobias
