Hi Tobias,
> This patch is a follow up to the resolve part, which permits TYPE=>CLASS.
> That approved patch is at
> http://gcc.gnu.org/ml/fortran/2013-06/msg00049.html (I didn't want to
> commit it without this trans*.c patch.)
>
> The attached patch adds support for:
> TYPE => CLASS
> additionally, it fixes some issues with
> CLASS => CLASS
> where the RHS is a polymorphic array function. Plus an issue with
> TYPE => TYPE
> where the LHS does rank remapping and the RHS is a function. Unfortunately,
> the patch is a bit messier than I had hoped for.
>
> Built and regtested on x86-64-gnu-linux.
> OK for the trunk?
yes, the patch looks basically ok to me. Just one thing I did not
quite understand:
@@ -6485,8 +6491,14 @@ gfc_trans_pointer_assignment (gfc_expr * expr1,
gfc_expr * expr2)
build_int_cst (gfc_charlen_type_node, 0));
}
+ /* It can happen that the LHS has BT_DERIVED but it is in reality
+ a polymorphic variable. */
+ 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);
+
gfc_add_modify (&block, lse.expr,
- fold_convert (TREE_TYPE (lse.expr), rse.expr));
+ fold_convert (TREE_TYPE (lse.expr), rse.expr));
gfc_add_block_to_block (&block, &rse.post);
gfc_add_block_to_block (&block, &lse.post);
How exactly can it happen that a polymorphic variable is BT_DERIVED?
Cheers,
Janus
