https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113503

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
For the warning case, I think
--- gcc/fortran/trans-expr.cc.jj        2024-02-14 14:26:19.764810614 +0100
+++ gcc/fortran/trans-expr.cc   2024-02-16 13:22:48.693104239 +0100
@@ -9253,19 +9253,20 @@ gfc_trans_subcomponent_assign (tree dest
           || (cm->ts.type == BT_CLASS && CLASS_DATA (cm)->attr.allocatable
               && expr->ts.type != BT_CLASS)))
     {
+      tree size;
+
       gfc_init_se (&se, NULL);
       gfc_conv_expr (&se, expr);
-      tree size;

+      /* The remainder of these instructions follow the if (cm->attr.pointer)
+        if (!cm->attr.dimension) part above.  */
+      gfc_add_block_to_block (&block, &se.pre);
       /* Take care about non-array allocatable components here.  The alloc_*
         routine below is motivated by the alloc_scalar_allocatable_for_
         assignment() routine, but with the realloc portions removed and
         different input.  */
       alloc_scalar_allocatable_subcomponent (&block, dest, cm, expr,
                                             se.string_length);
-      /* The remainder of these instructions follow the if (cm->attr.pointer)
-        if (!cm->attr.dimension) part above.  */
-      gfc_add_block_to_block (&block, &se.pre);

       if (expr->symtree && expr->symtree->n.sym->attr.proc_pointer
          && expr->symtree->n.sym->attr.dummy)
should fix this.  I don't see how code in se.pre could depend on what
alloc_scalar_allocatable_subcomponent emits, and clearly from the #c0 testcase
there can be a dependency in the other direction.

As for the ICE case, this is due to
      if (!expr2->ts.u.cl->backend_decl
          || !VAR_P (expr2->ts.u.cl->backend_decl))
        expr2->ts.u.cl->backend_decl = gfc_create_var (TREE_TYPE (slen),
                                                       "slen");
      gfc_add_modify (block, expr2->ts.u.cl->backend_decl, slen);
expr2->ts.u.cl->backend_decl here is INTEGER_CST and slen is the same
INTEGER_CST (20 in both cases), so changing expr2->ts.u.cl->backend_decl to a
temporary variable pushed into current block is definitely undesirable, it
means references to that slen var can be emitted even before or after the
containing block into which the temporary is pushed using pushdecl.

Reply via email to