[Bug fortran/93497] ICE in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:7594
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93497 markeggleston at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||markeggleston at gcc dot gnu.org Resolution|--- |FIXED --- Comment #9 from markeggleston at gcc dot gnu.org --- Committed to master and backported to gcc-10 and gcc-9.
[Bug fortran/93497] ICE in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:7594
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93497 --- Comment #8 from CVS Commits --- The releases/gcc-9 branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:cf7a6070c3688db20447643c789e157f73fc178b commit r9-8590-gcf7a6070c3688db20447643c789e157f73fc178b Author: Mark Eggleston Date: Thu May 7 08:29:14 2020 +0100 Fortran : ICE in gfc_conv_array_constructor_expr PR93497 Invalid expressions, such as those involving array constructors, used for the length of character types will cause an ICE. 2020-05-11 Mark Eggleston Backported from master 2020-05-13 Steven G. Kargl gcc/fortran/ PR fortran/93497 * decl.c (char_len_param_value): Check whether character length expression is of type EXPR_OP and if so simplify it. * resolve.c (resolve_charlen): Reject length if it has a rank. 2020-05-11 Mark Eggleston Backported from master 2020-05-13 Mark Eggleston gcc/testsuite/ PR fortran/93497 * gfortran.dg/pr88025.f90: Change in wording of error. * gfortran.dg/pr93497.f90: New test. * gfortran.dg/pr93714_1.f90: Change in wording of errors. * gfortran.dg/pr93714_2.f90: Change in wording of errors.
[Bug fortran/93497] ICE in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:7594
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93497 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:f2b77b928a54784d40faf1d86bd5b63f14756dc5 commit r10-8143-gf2b77b928a54784d40faf1d86bd5b63f14756dc5 Author: Mark Eggleston Date: Thu May 7 08:29:14 2020 +0100 Fortran : ICE in gfc_conv_array_constructor_expr PR93497 Invalid expressions, such as those involving array constructors, used for the length of character types will cause an ICE. 2020-05-11 Mark Eggleston Backported from master 2020-05-13 Steven G. Kargl gcc/fortran/ PR fortran/93497 * decl.c (char_len_param_value): Check whether character length expression is of type EXPR_OP and if so simplify it. * resolve.c (resolve_charlen): Reject length if it has a rank. 2020-05-11 Mark Eggleston Backported from master 2020-05-13 Mark Eggleston gcc/testsuite/ PR fortran/93497 * gfortran.dg/pr88025.f90: Change in wording of error. * gfortran.dg/pr93497.f90: New test. * gfortran.dg/pr93714_1.f90: Change in wording of errors. * gfortran.dg/pr93714_2.f90: Change in wording of errors.
[Bug fortran/93497] ICE in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:7594
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93497 --- Comment #6 from CVS Commits --- The master branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:f9f98e59a7f6663f31b671c44998190079097f97 commit r11-358-gf9f98e59a7f6663f31b671c44998190079097f97 Author: Mark Eggleston Date: Thu May 7 08:29:14 2020 +0100 Fortran : ICE in gfc_conv_array_constructor_expr PR93497 Invalid expressions, such as those involving array constructors, used for the length of character types will cause an ICE. 2020-05-13 Steven G. Kargl gcc/fortran/ PR fortran/93497 * decl.c (char_len_param_value): Check whether character length expression is of type EXPR_OP and if so simplify it. * resolve.c (resolve_charlen): Reject length if it has a rank. 2020-05-13 Mark Eggleston gcc/testsuite/ PR fortran/93497 * gfortran.dg/pr88025.f90: Change in wording of error. * gfortran.dg/pr93497.f90: New test. * gfortran.dg/pr93714_1.f90: Change in wording of errors. * gfortran.dg/pr93714_2.f90: Change in wording of errors.
[Bug fortran/93497] ICE in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:7594
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93497
--- Comment #5 from Steve Kargl ---
On Thu, Feb 06, 2020 at 03:38:05AM +, sgk at troutmask dot
apl.washington.edu wrote:
>
> --- Comment #4 from Steve Kargl ---
> On Thu, Feb 06, 2020 at 02:06:01AM +, 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",
>length->where);
[Bug fortran/93497] ICE in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:7594
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93497 --- Comment #4 from Steve Kargl --- On Thu, Feb 06, 2020 at 02:06:01AM +, sgk at troutmask dot apl.washington.edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93497 > > --- Comment #3 from Steve Kargl --- > On Thu, Feb 06, 2020 at 02:01:21AM +, 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.
[Bug fortran/93497] ICE in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:7594
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93497 --- Comment #3 from Steve Kargl --- On Thu, Feb 06, 2020 at 02:01:21AM +, 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.
[Bug fortran/93497] ICE in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:7594
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93497
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #2 from kargl at gcc dot gnu.org ---
This seems to do the trick. Patch is against svn r280157.
Note 1. The error message in gfortran.dg/pr88025.f90 needs to
be adjusted.
Note 2. This causes a regression with gfortran.dg/mapping_1.f90,
because the reference to the contained pure function tricky_helper
occurs before tricky_helper has been parsed. Thus, gfortran assumes
that tricky_helper is an impure function, which is no allowed here.
Oh well. The regression can be avoided by re-ordering the functions
in the test case.
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);
if ((*expr)->expr_type == EXPR_FUNCTION)
{
[Bug fortran/93497] ICE in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:7594
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93497 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, it's old (at least 4.8.0+).
