[PR,fortran/71203] - ICE on zero-length arrays or substrings

Message ID 5C7EE085.7020502@gmx.de
State New
Headers show
Series
  • [PR,fortran/71203] - ICE on zero-length arrays or substrings
Related show

Commit Message

Harald Anlauf March 5, 2019, 8:48 p.m.
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

Comments

Thomas Koenig March 5, 2019, 11:07 p.m. | #1
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
Harald Anlauf March 6, 2019, 9:31 p.m. | #2
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

>

Patch

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