Re: [Patch, fortran] PR37577 - [meta-bug] change internal array descriptor format for better syntax, C interop TR, rank 15

[Jakub Jelinek <jakub at redhat dot com>]

On Wed, Jan 24, 2018 at 10:30:41AM +0200, Janne Blomqvist wrote:
> On Tue, Jan 23, 2018 at 10:30 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> > On Tue, Jan 23, 2018 at 07:30:49PM +0000, Paul Richard Thomas wrote:
> >> Janne, Thanks.
> >>
> >> Jakub, is this OK with you?
> >
> > It is indeed quite late for such large ABI changes, some distributions are
> > about to start using the compiler by now.
> 
> Yes, we're (painfully) aware that it's quite late. The motivation is
> that the ABI for GCC 8 has already been broken, and if we get this
> patch in, we hope to avoid having to break it again for the next
> release. See also the discussion thread starting at
> 
> https://gcc.gnu.org/ml/fortran/2018-01/msg00150.html

Ok.

> >  How much was it tested (on which
> > targets)?
> 
> Dominique tested on Darwin, both -m32 and -m64:
> https://gcc.gnu.org/ml/fortran/2018-01/msg00156.html
> 
> Thomas tested on a "big-endian target" (I guess gcc110, that is,
> powerpc64-unknown-linux-gnu.):
> https://gcc.gnu.org/ml/fortran/2018-01/msg00163.html

Good.

> In addition to bumping up the max number of dimensions, another
> motivation is to bring the descriptor closer to the F2018 C
> interoperability descriptor. See
> https://gcc.gnu.org/wiki/ArrayDescriptorUpdate for an overview. One
> idea has been to use this C descriptor as the native GFortran
> descriptor; that might or might not ever happen.
> 
> But yes, the rank, type, and attribute fields could be of type
> (signed/unsigned) char, which would reduce the sizeof(dtype_type) from
> 24 to 16 bytes on a 64-bit target. For the F2018 C descriptor the type
> field must be signed, but currently we're not using the type field in
> the same way. The others can be unsigned or signed.

Given above my preference would be to keep version an int, and
change rank and type to signed char and attribute to signed short.
That way there will be no padding on either 32-bit or 64-bit targets,
and the structure will be at least a little bit smaller.
How much work would that be to change it in the patch?  I'd expect
just a few lines in gcc/fortran and few lines in libgfortran...

	Jakub