This is the mail archive of the
mailing list for the GCC project.
Re: [Patch, Fortran] PR57530 (Part 2 of 3) Support TYPE => CLASS
- From: Janus Weil <janus at gcc dot gnu dot org>
- To: Tobias Burnus <burnus at net-b dot de>
- Cc: gcc patches <gcc-patches at gcc dot gnu dot org>, gfortran <fortran at gcc dot gnu dot org>
- Date: Fri, 26 Jul 2013 22:45:47 +0200
- Subject: Re: [Patch, Fortran] PR57530 (Part 2 of 3) Support TYPE => CLASS
- References: <51F1A31F dot 3040404 at net-b dot de>
> 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
@@ -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?