Dear Fortranner,

while looking at an issue that bugged me when analyzing PR 102458,
I got sort of stuck at the following case:

subroutine s4
  integer, parameter :: n = 4
  integer            :: x(transfer(n, n)) = 1
  integer            :: y(2*int(n) - n)   = 2
  integer, parameter :: k = size (x)
  integer, parameter :: m = size (y)
  print *, k, m
  if (k /= m .or. m /= n) stop 1
end

This should be entirely legal code, and it is accepted by Intel.

We lack to simplify the SIZE:

pr102458-part2.f90:5:34:

    5 |   integer, parameter :: k = size (x)
      |                                  1
Error: Array 'x' at (1) is a variable, which does not reduce to a constant 
expression
pr102458-part2.f90:6:34:

    6 |   integer, parameter :: m = size (y)
      |                                  1
Error: Array 'y' at (1) is a variable, which does not reduce to a constant 
expression

My debugging sessions suggest that we fail to resolve the intrinsics -
in the present testcase it is TRANSFER and INT - at the right time,
so that simplification fails when processing SIZE(x), SIZE(y).

What is the best place to do this?

The following patch fixes this issue, but I am unsure whether this
is the right approach:

diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index b46cbfa90ab..5d37cfef183 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -7527,6 +7527,9 @@ simplify_size (gfc_expr *array, gfc_expr *dim, int k)
       return simplified;
     }

+  if (array->ref && array->ref->u.ar.as)
+    gfc_resolve_array_spec (array->ref->u.ar.as, 0);
+
   if (dim == NULL)
     {
       if (!gfc_array_size (array, &size))

It is also the only change so far that I can come up with which regtests
fine.  (Enforcing resolution too early can lead to funny problems.)

Comments?  Further insight on where to look instead?

Thanks,
Harald

Reply via email to