[Patch, Fortran] PR57530 (Part 2 of 3) Support TYPE => CLASS

[Janus Weil]

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