[Bug fortran/82720] [PDT] ICE in gfc_conv_component_ref, at fortran/trans-expr.c:2400

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4
                 CC|                            |kargl at gcc dot gnu.org,
                   |                            |pault at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
This hackish patch gives the expected result

Index: trans-types.c
===================================================================
--- trans-types.c       (revision 254051)
+++ trans-types.c       (working copy)
@@ -2667,11 +2667,18 @@ gfc_get_derived_type (gfc_symbol * derived, int codime
       else
        {
          if (c->ts.type == BT_CHARACTER
-             && !c->ts.deferred && !c->attr.pdt_string)
+             && !c->ts.deferred && !c->attr.pdt_string
+             && c->ts.u.cl->length->expr_type == EXPR_CONSTANT)
            {
              /* Evaluate the string length.  */
              gfc_conv_const_charlen (c->ts.u.cl);
              gcc_assert (c->ts.u.cl->backend_decl);
+           }
+         else if (c->ts.type == BT_CHARACTER
+                  && c->ts.u.cl->length->expr_type == EXPR_VARIABLE)
+           {
+             c->ts.u.cl->backend_decl
+               = build_int_cst (gfc_charlen_type_node, 2);
            }
          else if (c->ts.type == BT_CHARACTER)
            c->ts.u.cl->backend_decl


The first change prevents the gcc_assert() from triggering.
The second change is the simple hack to forcibly set the
string length to 2 to see if this allowed the code to compile.

I don't know if we should be evaluating c->ts.u.cl->length
at this point or earlier (in perhaps resolve.c)?