[PATCH] PR/83874: ICE initializing character array from derived type

[PATCH] PR/83874: ICE initializing character array from derived type

[Harald Anlauf]

The following obvious patch fixes a NULL pointer dereference:

Index: gcc/fortran/decl.c
===================================================================
--- gcc/fortran/decl.c  (revision 256671)
+++ gcc/fortran/decl.c  (working copy)
@@ -1718,7 +1718,7 @@
                    }
                  else if (init->expr_type == EXPR_ARRAY)
                    {
-                     if (init->ts.u.cl)
+                     if (init->ts.u.cl && init->ts.u.cl->length)
                        {
                          const gfc_expr *length = init->ts.u.cl->length;
                          if (length->expr_type != EXPR_CONSTANT)


Regtests without new failures on i686-pc-linux-gnu.
Testcase derived PR see below.

Whoever wants to take it, please commit to 8-trunk.
Due to the nature of the patch, it should be safe to backport
to the 6 and 7 branches.

Thanks,
Harald

---

Changelog:

2018-01-17  Harald Anlauf  <anlauf@gmx.de>

	PR fortran/83874
	* decl.c (add_init_expr_to_sym): Do not dereference NULL pointer.



Testsuite:

2018-01-17  Harald Anlauf  <anlauf@gmx.de>

	PR fortran/83874
	* gfortran.dg/pr83874.f90: New test.


Index: gfortran.dg/pr83874.f90
===================================================================
--- gfortran.dg/pr83874.f90     (revision 0)
+++ gfortran.dg/pr83874.f90     (revision 0)
@@ -0,0 +1,19 @@
+! { dg-do run }
+! PR fortran/83874
+! There was an ICE while initializing the character arrays
+!
+! Contributed by Harald Anlauf <anlauf@gmx.de>
+!
+program charinit
+  implicit none
+  type t
+     character(len=1) :: name
+  end type t
+  type(t), parameter :: z(2)= [ t ('a'), t ('b') ]
+  character(len=1), parameter :: names1(*) = z% name
+  character(len=*), parameter :: names2(2) = z% name
+  character(len=*), parameter :: names3(*) = z% name
+  if (.not. (names1(1) == "a" .and. names1(2) == "b")) call abort ()
+  if (.not. (names2(1) == "a" .and. names2(2) == "b")) call abort ()
+  if (.not. (names3(1) == "a" .and. names3(2) == "b")) call abort ()
+end program charinit

Re: [PATCH] PR/83874: ICE initializing character array from derived type

[Steve Kargl]

On Wed, Jan 17, 2018 at 10:10:29PM +0100, Harald Anlauf wrote:
> 
> Whoever wants to take it, please commit to 8-trunk.
>

I take it from the above that you do not have write
access to svn.  If you think that you will be taking
on additional bugs, write access can be arranged. 

-- 
Steve

Re: [PATCH] PR/83874: ICE initializing character array from derived type

[Harald Anlauf]

On 01/17/18 22:23, Steve Kargl wrote:
> On Wed, Jan 17, 2018 at 10:10:29PM +0100, Harald Anlauf wrote:
>>
>> Whoever wants to take it, please commit to 8-trunk.
>>
> 
> I take it from the above that you do not have write
> access to svn.  If you think that you will be taking
> on additional bugs, write access can be arranged. 
> 

No, I don't have write access.  I'm checking occasionally only
to take care of regressions, so it's not worth the effort.
Being able to fix the above quickly was pure luck.

Re: [PATCH] PR/83874: ICE initializing character array from derived type

[Steve Kargl]

On Wed, Jan 17, 2018 at 10:43:47PM +0100, Harald Anlauf wrote:
> On 01/17/18 22:23, Steve Kargl wrote:
> > On Wed, Jan 17, 2018 at 10:10:29PM +0100, Harald Anlauf wrote:
> >>
> >> Whoever wants to take it, please commit to 8-trunk.
> >>
> > 
> > I take it from the above that you do not have write
> > access to svn.  If you think that you will be taking
> > on additional bugs, write access can be arranged. 
> > 
> 
> No, I don't have write access.  I'm checking occasionally only
> to take care of regressions, so it's not worth the effort.
> Being able to fix the above quickly was pure luck.

Committed revision 256824.

If you ever decide to get mover involved, don't hesitate
to ask for write access.  We caould use the help.

-- 
Steve