Fixed as 'obviously correct' as
r11-6863-gbf8ee9e4eed6ba1a6d77b4cf168df480e1f954da

The _data component was preventing the detection of the procedure pointer
component and the conversion of the function. Once diagnosed, the fix is
obvious.

Regtested on FC33/x86_64 - OK in a few weeks for 9- and 10-branches?

Paul

Fortran: Fix for class functions as associated target [PR98565].

2021-01-22  Paul Thomas  <pa...@gcc.gnu.org>

gcc/fortran
PR fortran/98565
* trans-intrinsic.c (gfc_conv_associated): Do not add a _data
component for scalar class function targets. Instead, fix the
function result and access the _data from that.

gcc/testsuite/
PR fortran/98565
* gfortran.dg/associated_target_7.f90 : New test.
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 0e7c60a906b..5c9258c65c3 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -9002,7 +9002,8 @@ gfc_conv_associated (gfc_se *se, gfc_expr *expr)
   else
     {
       /* An optional target.  */
-      if (arg2->expr->ts.type == BT_CLASS)
+      if (arg2->expr->ts.type == BT_CLASS
+	  && arg2->expr->expr_type != EXPR_FUNCTION)
 	gfc_add_data_component (arg2->expr);
 
       if (scalar)
@@ -9023,6 +9024,11 @@ gfc_conv_associated (gfc_se *se, gfc_expr *expr)
 	      && arg2->expr->symtree->n.sym->attr.dummy)
 	    arg2se.expr = build_fold_indirect_ref_loc (input_location,
 						       arg2se.expr);
+	  if (arg2->expr->ts.type == BT_CLASS)
+	    {
+	      arg2se.expr = gfc_evaluate_now (arg2se.expr, &arg2se.pre);
+	      arg2se.expr = gfc_class_data_get (arg2se.expr);
+	    }
 	  gfc_add_block_to_block (&se->pre, &arg1se.pre);
 	  gfc_add_block_to_block (&se->post, &arg1se.post);
 	  gfc_add_block_to_block (&se->pre, &arg2se.pre);

Reply via email to