https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93497
--- Comment #5 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Thu, Feb 06, 2020 at 03:38:05AM +0000, sgk at troutmask dot
apl.washington.edu wrote:
>
> --- 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:
(old patch deleted)
> >
> > 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.
>
Here you go. Still need to adjust error message in gfortran.dg/pr88025.f90.
Whoever decides to push the change can fix it.
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 simplifiy it. This catches things
+ like CHARACTER(([1])). */
+ if ((*expr)->expr_type == EXPR_OP)
+ gfc_simplify_expr (*expr, 1);
if ((*expr)->expr_type == EXPR_FUNCTION)
{
Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c (revision 280157)
+++ gcc/fortran/resolve.c (working copy)
@@ -12297,7 +12300,7 @@ resolve_charlen (gfc_charlen *cl)
}
/* cl->length has been resolved. It should have an integer type. */
- if (cl->length->ts.type != BT_INTEGER)
+ if (cl->length->ts.type != BT_INTEGER || cl->length->rank != 0)
{
gfc_error ("Scalar INTEGER expression expected at %L",
&cl->length->where);
