Status of array descriptor changes

[Tobias Burnus]

Hi FX,

FX wrote:
> I will have some time to contribute to gfortran in the coming months,
> so I wondered if I could help bring the “array descriptor” work
> further along. But I have not followed at all recent developments, and
> don’t know what has been done (and where), and what remains to be
> done. Could one of you point me to a recent update on the status of
> this project, or write a short one?

The idea is to be 100% compatible to TS29113's array descriptor, see 
https://gcc.gnu.org/wiki/GFortranStandards#TS_29113_Further_Interoperability_of_Fortran_with_C

The spec permits to have additional fields, which are listed not in the 
TS's descriptor.

What remains to be done:

a) A few remaining test-suite regressions.

b) "offset": gfortran has an offset field, which seems to be used in 
some cases for lbound == 1 to calculate the offset. As TS29113 mandates 
for nonallocatable/nonpointer arrays that lower_bound == 0, one can 
presumably set both lower_lound and offset to zero. [The user can set 
the lower bound of the dummy argument (default: 1), but that's already 
taken care of in the callee – no need to force 1 (instead of 0) in the 
caller.]
A harder step is to remove the offset field as that's also use by the 
scalarizer. The removal is not required to be standard conform, but if 
it is essentially always zero, having the extra field is a waste of 
space and will confuse other users. In any case, the mixture of 
nonallocatable arrays which use GFC_TYPE_ARRAY_UBOUND etc. in the type 
and those which use array descriptors (and have no offset, extent 
instead of ubound) can be confusing – and causes trouble when trying to 
remove the code.
I think the code can also be optimized. Currently, the code checks for 
the value of the lower_bound+offset for nonallocatable/nonpointer 
arguments (i.e. assumed-shape array). But we know (already currently) 
that the first array element starts at "base_addr". Thus, there is no 
need to look at desc->lower_bound in that case.

c) Finish the conversion to byte-based "sm" (stride multiplier) instead 
of element-based "stride". Currently, a lot of code uses "a[i]". But it 
should use "a+i*sm" instead to support strides which are not multiples 
of the element. Caveat: The code should be such that it can be 
vectorized. That works usually if one knows that stride == 1 or 
"a->base_addr + i*TREE_SIZE(a->base_addr)". But it fails if one has "a + 
i*a->sm" as the compiler often does not see that "elem_len" == TREE_SIZE 
== sm. Thus, one has to be careful with the conversion and how one sets 
"sm" and "elem_len.
That affects the code through out the compiler, but what should come 
first is the conversion of gfc_conv_expr_descriptor.

I think those are the most important early items. Next come:

d) Conversion to use "elem_len" for arrays of strings. That's required 
for TS29113 with BIND(C) – and could simplify some intrinsics which 
currently take internally an array descriptor and a string-length 
argument. For TS29113, we also need to use a descriptor with scalar 
strings for BIND(C).

e) I think we should add a field/component for a CLASS pointer to the 
descriptor. At least for CLASS arrays and in particular for CLASS(*) 
[also for scalars] it would make the live easier as one then has space 
to store the string length for CLASS(*), pointer :: p => string. The 
current work around of storing the string length in the virtual table 
does not work well (and fails for allocatable string lengths.)

Tobias