On Tue, Jan 23, 2018 at 10:30 PM, Jakub Jelinek <ja...@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

>  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

>  Has the debug info side of things been adjusted too (the
> get_array_descr_info langhook)?

The patch at least modifies this function.

>> >> I took the design choice choice to replace the dtype with a structure:
>> >> typedef struct dtype_type
>> >> {
>> >>   size_t elem_len;
>> >>   int version;
>> >>   int rank;
>> >>   int type;
>> >>   int attribute;
>> >> }
>> >> dtype_type;
>
> Isn't this too wasteful?  rank will be just 0-15, right?
> What values can version have?  What type?  Do you need negative values for
> any of those?
> I think using unsigned char or unsigned short for some of those fields
> should be sufficient, yeah, they don't necessarily need to be bitfields.

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.




-- 
Janne Blomqvist

Reply via email to