[Bug fortran/91640] [9/10 Regression] ICE: gimplification failed (contiguous expr)

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91640

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|tkoenig at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

[Bug fortran/91640] [9/10 Regression] ICE: gimplification failed (contiguous expr)

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91640

--- Comment #5 from Tobias Burnus  ---
Author: burnus
Date: Sat Jan  4 08:19:51 2020
New Revision: 279879

URL: https://gcc.gnu.org/viewcvs?rev=279879=gcc=rev
Log:
Fortran] PR91640 – Fix call to contiguous dummy

PR fortran/91640
* trans-expr.c (gfc_conv_procedure_call): Avoid copy-out for
nonvariable
arguments to contiguous dummy args.  Avoid re-checking whether fsym is
NULL.

PR fortran/91640
* gfortran.dg/contiguous_10.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/contiguous_10.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/91640] [9/10 Regression] ICE: gimplification failed (contiguous expr)

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91640

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org

--- Comment #4 from Thomas Koenig  ---
Should be rather simple to fix.

[Bug fortran/91640] [9/10 Regression] ICE: gimplification failed (contiguous expr)

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91640

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #3 from Tobias Burnus  ---
(In reply to Richard Biener from comment #1)
> Note gimplification fails because we are evaluating in an lvalue context but
> got -_7 in the end.  In the past we've hacked around Fortran oddities by
> doing tem = -_7

Doing "tem = -_7" automatically would paper about a FE bug which is surely the
wrong approach!

For this ICE, gfortran is doing a copy-in/copy-out if the argument is not known
to be contiguous (i.e. not simply contiguous). — The copy-in ("tmp = -z") is
fine.

But if it is not a variable, copying-back does not make sense ("-z = tmp").

 * * *

Patch: https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00070.html

[Bug fortran/91640] [9/10 Regression] ICE: gimplification failed (contiguous expr)

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91640

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-03
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed.

[Bug fortran/91640] [9/10 Regression] ICE: gimplification failed (contiguous expr)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91640

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.3

--- Comment #1 from Richard Biener  ---
Note gimplification fails because we are evaluating in an lvalue context but
got -_7 in the end.  In the past we've hacked around Fortran oddities by
doing tem = -_7 and returning tem here, simply using a temporary as lvalue
which means the value assigned is lost (IIRC for things like assinging to
a literal constant which could happen in parameter context).

Full statement:

-_7 = MEM[(real(kind=4)[3] *)_4][_5]

and .original has

  D.3938 = -1;
  S.3 = 1;
  while (1)
{
  if (S.3 > 3) goto L.2;
  -z[S.3 + -1] = (*(real(kind=4)[3] * restrict) atmp.0.data)[S.3 +
D.3938];
  S.3 = S.3 + 1;
}
  L.2:;