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)?
