[PATCH] PR fortran/95979 - [10/11 Regression] ICE in get_kind, at fortran/simplify.c:129

[PATCH] PR fortran/95979 - [10/11 Regression] ICE in get_kind, at fortran/simplify.c:129

[Harald Anlauf]

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

Dear all,

the present PR turned out to be fixable rather easily, once Paul had the
idea to add another attempt of simplification of elemental intrinsics
for array-valued arguments.  There was some fallout which required only
small adjustments, see commit message below.

Regtested cleanly on x86_64-pc-linux-gnu.

OK for master / 10-branch?

Thanks,
Harald


PR fortran/95979 - ICE in get_kind, at fortran/simplify.c:129

Simplification of the elemental intrinsic INDEX with constant array-valued
arguments failed with an ICE or did not reduce to a constant array, depending
also on the presence of the optional KIND argument.  Add a further attempt of
simplification in the case of elemental intrinsics, and make sure the KIND
argument is not removed prematurely during simplification of INDEX.

gcc/fortran/ChangeLog:

	PR fortran/95979
	* expr.c (gfc_check_init_expr): Fix check of return code from
	gfc_intrinsic_func_interface.
	* intrinsic.c (gfc_intrinsic_func_interface): Add further attempt
	of simplification of elemental intrinsics with array arguments.
	* iresolve.c (gfc_resolve_index_func): Keep optional KIND argument
	for simplification of elemental use of INDEX.

gcc/testsuite/ChangeLog:

	PR fortran/95979
	* gfortran.dg/index_4.f90: New test.


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

diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index b87ae3d72a1..32d905ad179 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -2904,7 +2904,7 @@ gfc_check_init_expr (gfc_expr *e)
 		   && (e->value.function.isym->conversion == 1);

 	if (!conversion && (!gfc_is_intrinsic (sym, 0, e->where)
-	    || (m = gfc_intrinsic_func_interface (e, 0)) != MATCH_YES))
+	    || (m = gfc_intrinsic_func_interface (e, 0)) == MATCH_NO))
 	  {
 	    gfc_error ("Function %qs in initialization expression at %L "
 		       "must be an intrinsic function",
diff --git a/gcc/fortran/intrinsic.c b/gcc/fortran/intrinsic.c
index ef33587a774..f4dfcf77e0b 100644
--- a/gcc/fortran/intrinsic.c
+++ b/gcc/fortran/intrinsic.c
@@ -5038,6 +5038,11 @@ got_specific:
   if (!sym->module)
     gfc_intrinsic_symbol (sym);

+  /* Have another stab at simplification since elemental intrinsics with array
+     actual arguments would be missed by the calls above to do_simplify.  */
+  if (isym->elemental)
+    gfc_simplify_expr (expr, 1);
+
   return MATCH_YES;
 }

diff --git a/gcc/fortran/iresolve.c b/gcc/fortran/iresolve.c
index c2a4865f28f..994a9af4eb8 100644
--- a/gcc/fortran/iresolve.c
+++ b/gcc/fortran/iresolve.c
@@ -1296,11 +1296,7 @@ gfc_resolve_index_func (gfc_expr *f, gfc_actual_arglist *a)

   f->ts.type = BT_INTEGER;
   if (kind)
-    {
-      f->ts.kind = mpz_get_si ((kind)->value.integer);
-      a_back->next = NULL;
-      gfc_free_actual_arglist (a_kind);
-    }
+    f->ts.kind = mpz_get_si ((kind)->value.integer);
   else
     f->ts.kind = gfc_default_integer_kind;

diff --git a/gcc/testsuite/gfortran.dg/index_4.f90 b/gcc/testsuite/gfortran.dg/index_4.f90
new file mode 100644
index 00000000000..09093784c8c
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/index_4.f90
@@ -0,0 +1,19 @@
+! { dg-do run }
+! { dg-options "-fdump-tree-original" }
+! { dg-final { scan-tree-dump-times "string_index" 0 "original" } }
+! PR fortran/95979
+
+program p
+  implicit none
+  integer, parameter :: i0    = index( 'abcd',  'b' , .true. , kind=4)
+  integer, parameter :: i1(*) = index(['abcd'], 'b' , .true. , kind=4)
+  integer, parameter :: i2(*) = index( 'abcd' ,['b'], .true.         )
+  integer, parameter :: i3(*) = index( 'abcd' , 'b' ,[.true.]        )
+  integer, parameter :: i4(*) = index(['abcd'],['b'],[.true.], kind=8)
+  if (size (i1) /= 1) stop 1
+  if (size (i2) /= 1) stop 2
+  if (size (i3) /= 1) stop 3
+  if (size (i4) /= 1) stop 4
+  if (i0 /= 2)        stop 5
+  if (i1(1) /= 2 .or. i2(1) /= 2 .or. i3(1) /= 2 .or. i4(1) /= 2) stop 6
+end

*PING* [PATCH] PR fortran/95979 - [10/11 Regression] ICE in get_kind, at fortran/simplify.c:129

[Harald Anlauf]

*ping*

> Gesendet: Donnerstag, 08. Oktober 2020 um 20:44 Uhr
> Von: "Harald Anlauf" <anlauf@gmx.de>
> An: "fortran" <fortran@gcc.gnu.org>, "gcc-patches" <gcc-patches@gcc.gnu.org>
> Betreff: [PATCH] PR fortran/95979 - [10/11 Regression] ICE in get_kind, at fortran/simplify.c:129
>
> Dear all,
>
> the present PR turned out to be fixable rather easily, once Paul had the
> idea to add another attempt of simplification of elemental intrinsics
> for array-valued arguments.  There was some fallout which required only
> small adjustments, see commit message below.
>
> Regtested cleanly on x86_64-pc-linux-gnu.
>
> OK for master / 10-branch?
>
> Thanks,
> Harald
>
>
> PR fortran/95979 - ICE in get_kind, at fortran/simplify.c:129
>
> Simplification of the elemental intrinsic INDEX with constant array-valued
> arguments failed with an ICE or did not reduce to a constant array, depending
> also on the presence of the optional KIND argument.  Add a further attempt of
> simplification in the case of elemental intrinsics, and make sure the KIND
> argument is not removed prematurely during simplification of INDEX.
>
> gcc/fortran/ChangeLog:
>
> 	PR fortran/95979
> 	* expr.c (gfc_check_init_expr): Fix check of return code from
> 	gfc_intrinsic_func_interface.
> 	* intrinsic.c (gfc_intrinsic_func_interface): Add further attempt
> 	of simplification of elemental intrinsics with array arguments.
> 	* iresolve.c (gfc_resolve_index_func): Keep optional KIND argument
> 	for simplification of elemental use of INDEX.
>
> gcc/testsuite/ChangeLog:
>
> 	PR fortran/95979
> 	* gfortran.dg/index_4.f90: New test.
>
>

Re: *PING* [PATCH] PR fortran/95979 - [10/11 Regression] ICE in get_kind, at fortran/simplify.c:129

[Thomas Koenig]

Hello Harald,

> *ping*

>> OK for master / 10-branch?

OK for both (with a suitable waiting period).

Best regards

	Thomas