This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Status of array descriptor changes
- From: Tobias Burnus <burnus at net-b dot de>
- To: FX <fxcoudert at gmail dot com>, Dominique Dhumieres <dominiq at lps dot ens dot fr>, Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>
- Cc: gfortran <fortran at gcc dot gnu dot org>
- Date: Mon, 09 Jun 2014 21:01:52 +0200
- Subject: Re: Status of array descriptor changes
- Authentication-results: sourceware.org; auth=none
- References: <20140609173536 dot EBBE1105 at mailhost dot lps dot ens dot fr> <9EDB25BE-561A-4F6C-8A75-04ABA903E54F at gmail dot com>
Am 09.06.2014 20:50, schrieb FX:
Did you look at https://gcc.gnu.org/ml/fortran/2014-06/msg00015.html?
I did, but I must confess not all of it is clear. (What’s are span, sm[0] and elem_len in step (i), to start with?)
"sm" (byte-wise stride multiplier) and "elem_len" are described in
TS29113; "elem_len" is the size of a single element of the array, i.e.
in case of a string the string length times the size of a single
character (1 or 4 bytes); in case of REAL(16) it would be 16 bytes, in
case of a derived type, it would its byte size. "sm" is how many bytes
the next element of the array is away; for a contiguous array, sm ==
elem_len.
And "span" is "sm" in a work-around implementation for pointers. Thus,
the "span" work around should be remove, once we have properly implement
the "sm" support. (We do support "sm" at descriptor level, but often it
is just set to "stride*TREE_SIZE()" (or stride*elem_len), which does not
support strides which are not multiples of elem_len.)
Tobias