Hi Tobias,
Am 21.09.21 um 14:26 schrieb Tobias Burnus:
This patch requires the previously mentioned simple-loop-gen patch,
which also still needs to be reviewed:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579576.html
For the xfailed part of the new testcase, the updated array descriptor
is needed, but I think leaving it as xfailed for now - and reviewing
this patch first makes more sense.
I played around with your patch and was unable to break it.
Are you tracking the xfailed parts?
While playing I stumbled over the fact that when allocating an array
with a dimension that has extent 0, e.g. 4:-5, the lbound gets reset
to 1 and ubound set to 0. I tried to find this in the F2018 standard
but could not find this requirement. 9.7.1.2(1) only requires that
the extent is 0. Has the standard has changed in this respect?
size(a,dim=i) of an array is simply:
a.dim[i].ubound - a.dim[i].lbound + 1
except that the result is always >= 0, i.e. a(5:-10) has size 0.
Assumed-size arrays like as(5, -3:*) can be passed to assumed-rank
arrays – but, obviously, the upper bound is unknown. Without BIND(C),
the standard is quiet how those get transported but:
ubound(as,dim=2) == size(as,dim=2) == -1
However, for
..., allocatable :: c(:,:)
allocate (c(5,-4:-1))
the size(c,dim=2) is surely 4 and not -1. Thus, when passing it
to a
subroutine foo(x)
..., allocatable :: x(..)
it should also come out as size(x, dim=2) == 4.
To make the distinction, the allocatable/pointer attribute of the
dummy can be used – as an assumed-size array cannot be allocatable.
That's what is used in trans-intrinsic.c/trans-array.c – and the
main reason I started to generate inline code for the array size.
(Given that it permits optimizations and is a trivial code, I
also think that it makes sense in general.)
Agreed. Loop bounds in loop nests often refer to lbound/ubound/size.
But even when doing so, it still did not work properly as when
calling
call foo(d)
the bounds where not always reset such that the caller could still
receive ubound(d,dim=last_dim) == -1 - in the case it just happened
to be -1, be it for a zero-sized array or because the lbounds just
happend to be -1 or smaller. That's taken care of in trans-expr.c.
OK for mainline?
I am probably not the best person to review the trans-* parts, but
I did not spot anything I could point at, and the dump-tree looked
reasonable. Therefore OK from my side.
Thanks for the work!
Harald
Tobias
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201,
80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer:
Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München;
Registergericht München, HRB 106955
