| Message ID | trinity-db876c3b-57b9-4d78-aa19-70e3cfbe4f40-1622146834205@3c-app-gmx-bs44 |
|---|---|
| State | New |
| Headers | show |
| Series | PR fortran/99839 - [9/10/11/12 Regression] ICE in inline_matmul_assign, at fortran/frontend-passes.c:4234 | expand |
*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. > >
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. > > > > >
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