| Message ID | 5C7EE085.7020502@gmx.de |
|---|---|
| State | New |
| Headers | show |
| Series | [PR,fortran/71203] - ICE on zero-length arrays or substrings | expand |
Hi Harald, > To the reviewer: I am not 100% sure that my solution is correct, but it > solves the issues reported and regtests cleanly on x86_64-pc-linux-gnu. > > OK for trunk? Backports? I don't see how adding the charlen to the current namespace can hurt, so I think this is OK. Regarding backports: I don't think we need to backport every bug fix if does not fix a regression. (Officially, we are not even supposed to fix non-regressions on trunk at this point, but in practice this means that we should take care not to introduce risky patches. gfortran is not release critical, so we are free to break our own compiler without holding up all of gcc). Regards Thomas
Committed as rev.269444 to trunk, rev.269445 to 8-branch. Thanks for the review! Harald On 03/06/19 00:07, Thomas Koenig wrote: > Hi Harald, > >> To the reviewer: I am not 100% sure that my solution is correct, but it >> solves the issues reported and regtests cleanly on x86_64-pc-linux-gnu. >> >> OK for trunk? Backports? > > I don't see how adding the charlen to the current namespace can hurt, > so I think this is OK. > > Regarding backports: I don't think we need to backport every bug fix > if does not fix a regression. (Officially, we are not even > supposed to fix non-regressions on trunk at this point, but in practice > this means that we should take care not to introduce risky patches. > gfortran is not release critical, so we are free to break our own > compiler without holding up all of gcc). > > Regards > > Thomas >
Index: gcc/fortran/expr.c =================================================================== --- gcc/fortran/expr.c (revision 269400) +++ gcc/fortran/expr.c (working copy) @@ -1897,8 +1897,14 @@ string_len = 0; if (!p->ts.u.cl) - p->ts.u.cl = gfc_new_charlen (p->symtree->n.sym->ns, - NULL); + { + if (p->symtree) + p->ts.u.cl = gfc_new_charlen (p->symtree->n.sym->ns, + NULL); + else + p->ts.u.cl = gfc_new_charlen (gfc_current_ns, + NULL); + } else gfc_free_expr (p->ts.u.cl->length);
The attached patch addresses ICEs on several situations with zero-length arrays of strings or zero-length substrings, which were caused by a NULL pointer dereference in those particular situations. To the reviewer: I am not 100% sure that my solution is correct, but it solves the issues reported and regtests cleanly on x86_64-pc-linux-gnu. OK for trunk? Backports? Thanks, Harald P.S.: the PR has another ICE with integer array constructors which is unrelated and under investigation. 2019-03-05 Harald Anlauf <anlauf@gmx.de> PR fortran/71203 * expr.c (simplify_const_ref): Avoid null pointer dereference. 2019-03-05 Harald Anlauf <anlauf@gmx.de> PR fortran/71203 * gfortran.dg/substr_8.f90: New test. Index: gcc/testsuite/gfortran.dg/substr_8.f90 =================================================================== --- gcc/testsuite/gfortran.dg/substr_8.f90 (nonexistent) +++ gcc/testsuite/gfortran.dg/substr_8.f90 (working copy) @@ -0,0 +1,15 @@ +! { dg-do run } +! PR fortran/71203 - used to ICE on zero-length arrays or substrings +! Derived from original test cases by Gerhard Steinmetz + +program p + implicit none + character(3), parameter :: a(4) = ' ' + character(*), parameter :: b(4) = 'abc' + character(*), parameter :: x(*) = a(2:2)(3:1) + character(*), parameter :: y(*) = a(2:1)(3:1) + character(*), parameter :: z(*) = b(2:1)(2:3) + if (size (x) /= 1 .or. len(x) /= 0) stop 1 + if (size (y) /= 0 .or. len(y) /= 0) stop 2 + if (size (z) /= 0 .or. len(z) /= 2) stop 3 +end