[PATCH] PR fortran/99839 - [9/10/11/12 Regression] ICE in inline_matmul_assign, at fortran/frontend-passes.c:4234

[PATCH] PR fortran/99839 - [9/10/11/12 Regression] ICE in inline_matmul_assign, at fortran/frontend-passes.c:4234

[Harald Anlauf]

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

Dear Fortranners,

frontend optimization tries to inline matmul, but then it also needs
to take care of the assignment to the result array.  If that one is
not of canonical type, we currently get an ICE.  The straightforward
solution is to simply punt in those cases and avoid inlining.

Regtested on x86_64-pc-linux-gnu.

OK for mainline?  Backport to affected branches?

Thanks,
Harald


Fortran - ICE in inline_matmul_assign

Restrict inlining of matmul to those cases where assignment to the
result array does not need special treatment.

gcc/fortran/ChangeLog:

	PR fortran/99839
	* frontend-passes.c (inline_matmul_assign): Do not inline matmul
	if the assignment to the resulting array if it is not of canonical
	type (real/integer/complex/logical).

gcc/testsuite/ChangeLog:

	PR fortran/99839
	* gfortran.dg/inline_matmul_25.f90: New test.


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

diff --git a/gcc/fortran/frontend-passes.c b/gcc/fortran/frontend-passes.c
index ffe2db4881d..8aa4cf0eca7 100644
--- a/gcc/fortran/frontend-passes.c
+++ b/gcc/fortran/frontend-passes.c
@@ -4193,6 +4193,19 @@ inline_matmul_assign (gfc_code **c, int *walk_subtrees,
   if (m_case == none)
     return 0;

+  /* We only handle assignment to numeric or logical variables.  */
+  switch(expr1->ts.type)
+    {
+    case BT_INTEGER:
+    case BT_LOGICAL:
+    case BT_REAL:
+    case BT_COMPLEX:
+      break;
+
+    default:
+      return 0;
+    }
+
   ns = insert_block ();

   /* Assign the type of the zero expression for initializing the resulting
diff --git a/gcc/testsuite/gfortran.dg/inline_matmul_25.f90 b/gcc/testsuite/gfortran.dg/inline_matmul_25.f90
new file mode 100644
index 00000000000..df8ad06c123
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/inline_matmul_25.f90
@@ -0,0 +1,9 @@
+! { dg-do compile }
+! { dg-options "-ffrontend-optimize" }
+! PR fortran/99839 - ICE in inline_matmul_assign
+
+program p
+  real :: x(3, 3) = 1.0
+  class(*), allocatable :: z(:, :)
+  z = matmul(x, x)
+end

PING [PATCH] PR fortran/99839 - [9/10/11/12 Regression] ICE in inline_matmul_assign, at fortran/frontend-passes.c:4234

[Harald Anlauf]

*PING*

> Gesendet: Donnerstag, 27. Mai 2021 um 22:20 Uhr
> Von: "Harald Anlauf" <anlauf@gmx.de>
> An: "fortran" <fortran@gcc.gnu.org>, "gcc-patches" <gcc-patches@gcc.gnu.org>
> Betreff: [PATCH] PR fortran/99839 - [9/10/11/12 Regression] ICE in inline_matmul_assign, at fortran/frontend-passes.c:4234
>
> Dear Fortranners,
>
> frontend optimization tries to inline matmul, but then it also needs
> to take care of the assignment to the result array.  If that one is
> not of canonical type, we currently get an ICE.  The straightforward
> solution is to simply punt in those cases and avoid inlining.
>
> Regtested on x86_64-pc-linux-gnu.
>
> OK for mainline?  Backport to affected branches?
>
> Thanks,
> Harald
>
>
> Fortran - ICE in inline_matmul_assign
>
> Restrict inlining of matmul to those cases where assignment to the
> result array does not need special treatment.
>
> gcc/fortran/ChangeLog:
>
> 	PR fortran/99839
> 	* frontend-passes.c (inline_matmul_assign): Do not inline matmul
> 	if the assignment to the resulting array if it is not of canonical
> 	type (real/integer/complex/logical).
>
> gcc/testsuite/ChangeLog:
>
> 	PR fortran/99839
> 	* gfortran.dg/inline_matmul_25.f90: New test.
>
>

Re: PING [PATCH] PR fortran/99839 - [9/10/11/12 Regression] ICE in inline_matmul_assign, at fortran/frontend-passes.c:4234

[Paul Richard Thomas]

Hi Harald,

Looks good to me - OK for as many branches as you have sufficient fortitude
for.

Regards

Paul


On Thu, 3 Jun 2021 at 21:22, Harald Anlauf via Fortran <fortran@gcc.gnu.org>
wrote:

> *PING*
>
> > Gesendet: Donnerstag, 27. Mai 2021 um 22:20 Uhr
> > Von: "Harald Anlauf" <anlauf@gmx.de>
> > An: "fortran" <fortran@gcc.gnu.org>, "gcc-patches" <
> gcc-patches@gcc.gnu.org>
> > Betreff: [PATCH] PR fortran/99839 - [9/10/11/12 Regression] ICE in
> inline_matmul_assign, at fortran/frontend-passes.c:4234
> >
> > Dear Fortranners,
> >
> > frontend optimization tries to inline matmul, but then it also needs
> > to take care of the assignment to the result array.  If that one is
> > not of canonical type, we currently get an ICE.  The straightforward
> > solution is to simply punt in those cases and avoid inlining.
> >
> > Regtested on x86_64-pc-linux-gnu.
> >
> > OK for mainline?  Backport to affected branches?
> >
> > Thanks,
> > Harald
> >
> >
> > Fortran - ICE in inline_matmul_assign
> >
> > Restrict inlining of matmul to those cases where assignment to the
> > result array does not need special treatment.
> >
> > gcc/fortran/ChangeLog:
> >
> >       PR fortran/99839
> >       * frontend-passes.c (inline_matmul_assign): Do not inline matmul
> >       if the assignment to the resulting array if it is not of canonical
> >       type (real/integer/complex/logical).
> >
> > gcc/testsuite/ChangeLog:
> >
> >       PR fortran/99839
> >       * gfortran.dg/inline_matmul_25.f90: New test.
> >
> >
>


-- 
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein