https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93497
--- Comment #4 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- On Thu, Feb 06, 2020 at 02:06:01AM +0000, sgk at troutmask dot apl.washington.edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93497 > > --- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- > On Thu, Feb 06, 2020 at 02:01:21AM +0000, kargl at gcc dot gnu.org wrote: > > > > Index: gcc/fortran/decl.c > > =================================================================== > > --- gcc/fortran/decl.c (revision 280157) > > +++ gcc/fortran/decl.c (working copy) > > @@ -1056,6 +1072,11 @@ char_len_param_value (gfc_expr **expr, bool > > *deferred) > > > > if (!gfc_expr_check_typed (*expr, gfc_current_ns, false)) > > return MATCH_ERROR; > > + > > + /* If gfortran gets an EXPR_OP, try to reduce it. This catches things > > + like CHARACTER(([1])). */ > > + if ((*expr)->expr_type == EXPR_OP) > > + gfc_reduce_init_expr (*expr); > > > > Another possibility to fix the bug is to use gfc_expr_walker > from frontend-passes.c to check if the expression has an array > result. Don't know how to do that. > Another possibility is to find where in resolve.c that the charlen is reduced and issue an appropriate error when an array-valued length is found.
