[PATCH] PR fortran/99348, 102521 - ICEs when initializing DT parameter arrays from scalar

[PATCH] PR fortran/99348, 102521 - ICEs when initializing DT parameter arrays from scalar

[Harald Anlauf]

[-- Attachment #1: Type: text/plain, Size: 802 bytes --]

Dear Fortranners,

when initializing parameter arrays from scalars, we did handle only
the case init->expr_type == EXPR_CONSTANT, which misses the case of
derived types.  As a consequence the constructor for the r.h.s. was
not set up, which later led to different ICEs.

To solve this I looked at gfc_simplify_spread.  I was contemplating
whether to also copy the logic to make this initialization dependent
on -fmax-array-constructor.  I chose not to, because there is no
sensible and simple fallback available to handle that case while
allowing the access to array elements.  We could instead make that
a warning.

Comments / opinions?

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

As this is an ICE on valid, potentially useful code,
I'd like to backport this to 11-branch.

Thanks,
Harald


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: pr99348-102521.diff --]
[-- Type: text/x-patch, Size: 2373 bytes --]

Fortran: handle initialization of derived type parameter arrays from scalar

gcc/fortran/ChangeLog:

	PR fortran/99348
	PR fortran/102521
	* decl.c (add_init_expr_to_sym): Extend initialization of
	parameter arrays from scalars to handle derived types.

gcc/testsuite/ChangeLog:

	PR fortran/99348
	PR fortran/102521
	* gfortran.dg/parameter_array_init_8.f90: New test.

diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index b3c65b7175b..d6a22d13451 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -2228,12 +2228,16 @@ add_init_expr_to_sym (const char *name, gfc_expr **initp, locus *var_locus)
 	  gfc_expr *array;
 	  int n;
 	  if (sym->attr.flavor == FL_PARAMETER
-		&& init->expr_type == EXPR_CONSTANT
-		&& spec_size (sym->as, &size)
-		&& mpz_cmp_si (size, 0) > 0)
+	      && gfc_is_constant_expr (init)
+	      && (init->expr_type == EXPR_CONSTANT
+		  || init->expr_type == EXPR_STRUCTURE)
+	      && spec_size (sym->as, &size)
+	      && mpz_cmp_si (size, 0) > 0)
 	    {
 	      array = gfc_get_array_expr (init->ts.type, init->ts.kind,
 					  &init->where);
+	      if (init->ts.type == BT_DERIVED)
+		array->ts.u.derived = init->ts.u.derived;
 	      for (n = 0; n < (int)mpz_get_si (size); n++)
 		gfc_constructor_append_expr (&array->value.constructor,
 					     n == 0
diff --git a/gcc/testsuite/gfortran.dg/parameter_array_init_8.f90 b/gcc/testsuite/gfortran.dg/parameter_array_init_8.f90
new file mode 100644
index 00000000000..05b2e424a3f
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/parameter_array_init_8.f90
@@ -0,0 +1,25 @@
+! { dg-do run }
+! PR fortran/99348
+! PR fortran/102521
+! Check simplifications for initialization of DT paramameter arrays
+
+program p
+  type t
+     integer :: n
+  end type
+  type(t), parameter :: a(4)   = t(1)
+  type(t), parameter :: d(*)   = a
+  type(t), parameter :: b(2,2) = reshape(d, [2,2])
+  integer, parameter :: nn     = b(2,2)% n
+  type u
+     character(3) :: c
+  end type
+  type(u),      parameter :: x(2,3) = u('ab')
+  type(u),      parameter :: y(*,*) = transpose (x)
+  character(*), parameter :: c      = y(3,2)% c
+  integer,      parameter :: lc     = c% len
+  integer,      parameter :: lyc    = len (y(3,2)% c)
+! integer,      parameter :: lxc    = x(1,1)% c% len    ! fails (pr101735?)
+  if (nn /= 1) stop 1
+  if (lc /= 3 .or. lyc /= 3 .or. c /= "ab ") stop 2
+end

*PING* [PATCH] PR fortran/99348, 102521 - ICEs when initializing DT parameter arrays from scalar

[Harald Anlauf]

*Ping*

Am 03.10.21 um 21:20 schrieb Harald Anlauf via Fortran:
> Dear Fortranners,
> 
> when initializing parameter arrays from scalars, we did handle only
> the case init->expr_type == EXPR_CONSTANT, which misses the case of
> derived types.  As a consequence the constructor for the r.h.s. was
> not set up, which later led to different ICEs.
> 
> To solve this I looked at gfc_simplify_spread.  I was contemplating
> whether to also copy the logic to make this initialization dependent
> on -fmax-array-constructor.  I chose not to, because there is no
> sensible and simple fallback available to handle that case while
> allowing the access to array elements.  We could instead make that
> a warning.
> 
> Comments / opinions?
> 
> Regtested on x86_64-pc-linux-gnu.  OK for mainline?
> 
> As this is an ICE on valid, potentially useful code,
> I'd like to backport this to 11-branch.
> 
> Thanks,
> Harald
> 

*PING* [PATCH] PR fortran/99348, 102521 - ICEs when initializing DT parameter arrays from scalar

[Harald Anlauf]

*Ping*

Am 03.10.21 um 21:20 schrieb Harald Anlauf via Fortran:
> Dear Fortranners,
>
> when initializing parameter arrays from scalars, we did handle only
> the case init->expr_type == EXPR_CONSTANT, which misses the case of
> derived types.  As a consequence the constructor for the r.h.s. was
> not set up, which later led to different ICEs.
>
> To solve this I looked at gfc_simplify_spread.  I was contemplating
> whether to also copy the logic to make this initialization dependent
> on -fmax-array-constructor.  I chose not to, because there is no
> sensible and simple fallback available to handle that case while
> allowing the access to array elements.  We could instead make that
> a warning.
>
> Comments / opinions?
>
> Regtested on x86_64-pc-linux-gnu.  OK for mainline?
>
> As this is an ICE on valid, potentially useful code,
> I'd like to backport this to 11-branch.
>
> Thanks,
> Harald
>

Re: *PING* [PATCH] PR fortran/99348, 102521 - ICEs when initializing DT parameter arrays from scalar

[Jerry D]

This one looks OK.  Sorry I missed it earlier. Thanks again for the patch!

Jerry

On 10/9/21 12:27 PM, Harald Anlauf via Fortran wrote:
> *Ping*
>
> Am 03.10.21 um 21:20 schrieb Harald Anlauf via Fortran:
>> Dear Fortranners,
>>
>> when initializing parameter arrays from scalars, we did handle only
>> the case init->expr_type == EXPR_CONSTANT, which misses the case of
>> derived types.  As a consequence the constructor for the r.h.s. was
>> not set up, which later led to different ICEs.
>>
>> To solve this I looked at gfc_simplify_spread.  I was contemplating
>> whether to also copy the logic to make this initialization dependent
>> on -fmax-array-constructor.  I chose not to, because there is no
>> sensible and simple fallback available to handle that case while
>> allowing the access to array elements.  We could instead make that
>> a warning.
>>
>> Comments / opinions?
>>
>> Regtested on x86_64-pc-linux-gnu.  OK for mainline?
>>
>> As this is an ICE on valid, potentially useful code,
>> I'd like to backport this to 11-branch.
>>
>> Thanks,
>> Harald
>>
>
>