[RFC] Native Coarrays (finally!) [Review part 3]

[Thomas Koenig]

Am 16.10.20 um 10:45 schrieb Andre Vehreschild:
> Hi Thomas, hi Nicolas,
> 
> I agree with you, that doing copies of array's data should be avoided, but
> please keep in mind, that the gfc_descriptor_t is so to say "public". I.e.,
> there are also libraries using it, that are not in the gcc repo and those
> depend on the descriptor being usable as is.

I am quite aware of that.

However, what can happen?

Since the last ABI revision, we set the span. Old code calling a new
library will work anyway because it will do the packing / unpacking.
New code calling the old library is something we do not, in general,
support (we do add new functions to the library), but it would also work
because we set the span anyway.

The only thing we cannot handle is new user code (without the temporary)
calling old user code (which does not handle the span).  We cannot
change that without an ABI upgrade, but upgrading the library will
not be affected.

> Furthermore, the span-member is not necessarily the size of the data element in
> the array, right @Paul?

That's the point of using the span.

> Assume a structure whose data components need an odd
> number of bytes. Putting this structure into an array, the span-member would
> hold the padded data size, right?

Not the size, the distance.  Fortunately, alignment requirements mean
that this will work out OK.

> I am not sure about the above, therefore Paul is in copy. This is just like I
> have memorized it (may be wrong).
> 
> Anyway, my remark was more the comment not being precise or rather misleading.
> I would expect something like "/* store byte-based strides here */". Which
> makes it more clear, what will been done.

OK :-)

Thanks for looking at this!

Best regards

	Thomas