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