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

[Tobias Burnus <burnus at net-b dot de>]

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