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

[Tom de Vries]

Hi,

this ( r257065 ) caused: PR84088 - "[nvptx] 
libgomp.oacc-fortran/declare-*.f90 execution fails" ( 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84088 ).


Thanks,
- Tom

On 01/24/2018 10:05 AM, Paul Richard Thomas wrote:

Hi Jakub,

The lateness is indeed embarrassing but couldn't be helped.


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


I can do that this afternoon. It's little more work than changing a
couple of typedefs. There are one or two other, cosmetic changes to
make too.

Thanks

Paul

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

[Paul Richard Thomas]

Hi Jakub,

The lateness is indeed embarrassing but couldn't be helped.

> 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

I can do that this afternoon. It's little more work than changing a
couple of typedefs. There are one or two other, cosmetic changes to
make too.

Thanks

Paul

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

[Jakub Jelinek]

On Wed, Jan 24, 2018 at 10:30:41AM +0200, Janne Blomqvist wrote:
> On Tue, Jan 23, 2018 at 10:30 PM, Jakub Jelinek  wrote:
> > On Tue, Jan 23, 2018 at 07:30:49PM +, 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

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

[Janne Blomqvist]

On Tue, Jan 23, 2018 at 10:30 PM, Jakub Jelinek  wrote:
> On Tue, Jan 23, 2018 at 07:30:49PM +, 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

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

[Jakub Jelinek]

On Tue, Jan 23, 2018 at 07:30:49PM +, 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.  How much was it tested (on which
targets)?  Has the debug info side of things been adjusted too (the
get_array_descr_info langhook)?

> >> 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.

Jakub

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

[Paul Richard Thomas]

Janne, Thanks.

Jakub, is this OK with you?

Paul

On 23 January 2018 at 19:09, Janne Blomqvist  wrote:
> On Mon, Jan 22, 2018 at 9:12 PM, Paul Richard Thomas
>  wrote:
>> This patch has been triggered by Thomas's recent message to the list.
>> Not only did I start work late relative to stage 3 but debugging took
>> somewhat longer than anticipated. Therefore, to get this committed
>> asap, we will have to beg the indulgence of the release managers and
>> prompt review and/or testing by fortran maintainers. (Dominique has
>> already undertaken to test -m32.)
>>
>> The patch delivers rank up to 15 for F2008, the descriptor information
>> needed to enact the F2018 C descriptor macros and an attribute field
>> to store such information as pointer/allocatable, contiguous etc..
>> Only the first has been enabled so far but it was necessary to submit
>> the array descriptor changes now to avoid any further ABI breakage in
>> 9.0.0.
>>
>> 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;
>>
>> This choice was intended to reduce the changes to a minimum, since in
>> most references to the dtype, one dtype is assigned to another.
>>
>> The F2018 interop defines the 'type and 'attribute fields to be signed
>> char types. I used this intially but found that using int was the best
>> way to silence the warnings about padding since it also allows for
>> more attribute information to be carried.
>>
>> Some parts of the patch (eg. in get_scalar_to_descriptor_type) look as
>> if latent bugs were uncovered by the change to the descriptor. If so,
>> the time spent debugging was well worthwhile.
>>
>> It should be noted that some of the intrinsics, which use switch/case
>> for the type/kind selection, limit the effective element size that
>> they handle to the maximum value of size_t, less 7 bits. A bit of
>> straightforward work there would fix this limitation and would allow
>> the GFC_DTYPE shifts and masks to be eliminated.
>>
>> Bootstraps and regtests on FC23/x86_64 - OK for trunk?
>
> In trans-types.c:
>
> structure dtype_type dtype;
>
> Should be "struct dtype_type dtype". (This is in a comment, so doesn't
> affect the code, but still).
>
> I have to say, the patch is much smaller and less invasive than I had
> feared for such a fundamental change. I guess you were right about
> making dtype it's own type.
>
> As for the DTYPE shifting and masking thing, now that I have read the
> patch, if I understood it correctly, that's an internal issue in
> libgfortran and has no effect on the descriptor.  That being said, the
> F2018 C descriptor has both the type and kind encoded into the type
> field, see table 18.4 in F2018 N2146. (In a way that's redundant,
> since the type and the elem_len fields suffice to figure out the
> type combination). Anyway, is there a case for following suit,
> and if so, is it a too invasive change at this point?
>
> In any case, since we seem to agree that we have no big lingering
> issues that would require us to break the ABI again for GCC 9, IMHO
> this is Ok for trunk. You might want to get an explicit Ok from the
> release manager, though.
>
> --
> Janne Blomqvist



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

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

[Janne Blomqvist]

On Mon, Jan 22, 2018 at 9:12 PM, Paul Richard Thomas
 wrote:
> This patch has been triggered by Thomas's recent message to the list.
> Not only did I start work late relative to stage 3 but debugging took
> somewhat longer than anticipated. Therefore, to get this committed
> asap, we will have to beg the indulgence of the release managers and
> prompt review and/or testing by fortran maintainers. (Dominique has
> already undertaken to test -m32.)
>
> The patch delivers rank up to 15 for F2008, the descriptor information
> needed to enact the F2018 C descriptor macros and an attribute field
> to store such information as pointer/allocatable, contiguous etc..
> Only the first has been enabled so far but it was necessary to submit
> the array descriptor changes now to avoid any further ABI breakage in
> 9.0.0.
>
> 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;
>
> This choice was intended to reduce the changes to a minimum, since in
> most references to the dtype, one dtype is assigned to another.
>
> The F2018 interop defines the 'type and 'attribute fields to be signed
> char types. I used this intially but found that using int was the best
> way to silence the warnings about padding since it also allows for
> more attribute information to be carried.
>
> Some parts of the patch (eg. in get_scalar_to_descriptor_type) look as
> if latent bugs were uncovered by the change to the descriptor. If so,
> the time spent debugging was well worthwhile.
>
> It should be noted that some of the intrinsics, which use switch/case
> for the type/kind selection, limit the effective element size that
> they handle to the maximum value of size_t, less 7 bits. A bit of
> straightforward work there would fix this limitation and would allow
> the GFC_DTYPE shifts and masks to be eliminated.
>
> Bootstraps and regtests on FC23/x86_64 - OK for trunk?

In trans-types.c:

structure dtype_type dtype;

Should be "struct dtype_type dtype". (This is in a comment, so doesn't
affect the code, but still).

I have to say, the patch is much smaller and less invasive than I had
feared for such a fundamental change. I guess you were right about
making dtype it's own type.

As for the DTYPE shifting and masking thing, now that I have read the
patch, if I understood it correctly, that's an internal issue in
libgfortran and has no effect on the descriptor.  That being said, the
F2018 C descriptor has both the type and kind encoded into the type
field, see table 18.4 in F2018 N2146. (In a way that's redundant,
since the type and the elem_len fields suffice to figure out the
type combination). Anyway, is there a case for following suit,
and if so, is it a too invasive change at this point?

In any case, since we seem to agree that we have no big lingering
issues that would require us to break the ABI again for GCC 9, IMHO
this is Ok for trunk. You might want to get an explicit Ok from the
release manager, though.

-- 
Janne Blomqvist

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

[Thomas Koenig]

Hi Paul,


Could somebody please review the patch?


I'd say the patch is OK for trunk. I have also tested this on
a big-endian system, and things worked.

I will look at the resulting fallout of the GFC_DTYPE_TYPE_SIZE
stuff.

Thanks a lot for your work!

Regards

Thomas

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

[Thomas Koenig]

Hi Jerry,


Do you mean adding something like this:

diff --git a/libgfortran/libgfortran.h b/libgfortran/libgfortran.h
index 4c643b7e17b..c86e0b45e1d 100644
--- a/libgfortran/libgfortran.h
+++ b/libgfortran/libgfortran.h
@@ -600,6 +600,7 @@ typedef struct st_parameter_common
GFC_INTEGER_4 line;
CHARACTER2 (iomsg);
GFC_INTEGER_4 *iostat;
+  void *reserved;
  }
  st_parameter_common;


Yes, this is what I had in mind.

Regards

Thomas

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

[Paul Richard Thomas]

Could somebody please review the patch?

Thanks

Paul


On 23 January 2018 at 06:13, Dominique d'Humières
 wrote:
> Dear Paul,
>
> The test suite passed without new regression with both -m32 and -m64.
>
> Thanks for the work,
>
> Dominique



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

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

[Dominique d'Humières]

Dear Paul,

The test suite passed without new regression with both -m32 and -m64.

Thanks for the work,

Dominique

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

[Jerry DeLisle]

On 01/22/2018 12:24 PM, Thomas Koenig wrote:
> Am 22.01.2018 um 20:59 schrieb Janne Blomqvist:
>> On Mon, Jan 22, 2018 at 9:12 PM, Paul Richard Thomas
>>  wrote:
>>> This patch has been triggered by Thomas's recent message to the list.
>>> Not only did I start work late relative to stage 3 but debugging took
>>> somewhat longer than anticipated. Therefore, to get this committed
>>> asap, we will have to beg the indulgence of the release managers and
>>> prompt review and/or testing by fortran maintainers. (Dominique has
>>> already undertaken to test -m32.)
>>
>> I think that if we can "guarantee" that we're happy with the current
>> ABI for GCC 9 (and hopefully 10, 11, ...?) we have a quite strong case
>> for committing it now. But if anybody if planning on doing some
>> ABI-breaking work in the foreseeable future then maybe we should wait
>> until GCC 9 stage1 opens. Anybody with such plans?
> 
> For asynchronous I/O, we could add a pointer to void (unused at
> present) for later use.  That's all from my side.
> 

Do you mean adding something like this:

diff --git a/libgfortran/libgfortran.h b/libgfortran/libgfortran.h
index 4c643b7e17b..c86e0b45e1d 100644
--- a/libgfortran/libgfortran.h
+++ b/libgfortran/libgfortran.h
@@ -600,6 +600,7 @@ typedef struct st_parameter_common
   GFC_INTEGER_4 line;
   CHARACTER2 (iomsg);
   GFC_INTEGER_4 *iostat;
+  void *reserved;
 }
 st_parameter_common;

and the corresponding front end side.
>  snip --

Regarding Paul's patch, assuming the -m32 tests can be confirmed I think the
patch should go in now.

Jerry

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

[Steve Kargl]

On Mon, Jan 22, 2018 at 09:59:41PM +0200, Janne Blomqvist wrote:
> On Mon, Jan 22, 2018 at 9:12 PM, Paul Richard Thomas
>  wrote:
> > This patch has been triggered by Thomas's recent message to the list.
> > Not only did I start work late relative to stage 3 but debugging took
> > somewhat longer than anticipated. Therefore, to get this committed
> > asap, we will have to beg the indulgence of the release managers and
> > prompt review and/or testing by fortran maintainers. (Dominique has
> > already undertaken to test -m32.)
> 
> I think that if we can "guarantee" that we're happy with the current
> ABI for GCC 9 (and hopefully 10, 11, ...?) we have a quite strong case
> for committing it now. But if anybody if planning on doing some
> ABI-breaking work in the foreseeable future then maybe we should wait
> until GCC 9 stage1 opens. Anybody with such plans?
> 

I don't have any plans to break the ABI in 9.0.  OTOH, if the
patch isn't included in 8.0, then we know that the ABI will be
broken for 9.0.  I think we should shoot for stabilizing the
ABI by including this in 8.0.

-- 
Steve

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

[Thomas Koenig]

Am 22.01.2018 um 20:59 schrieb Janne Blomqvist:

On Mon, Jan 22, 2018 at 9:12 PM, Paul Richard Thomas
 wrote:

This patch has been triggered by Thomas's recent message to the list.
Not only did I start work late relative to stage 3 but debugging took
somewhat longer than anticipated. Therefore, to get this committed
asap, we will have to beg the indulgence of the release managers and
prompt review and/or testing by fortran maintainers. (Dominique has
already undertaken to test -m32.)


I think that if we can "guarantee" that we're happy with the current
ABI for GCC 9 (and hopefully 10, 11, ...?) we have a quite strong case
for committing it now. But if anybody if planning on doing some
ABI-breaking work in the foreseeable future then maybe we should wait
until GCC 9 stage1 opens. Anybody with such plans?


For asynchronous I/O, we could add a pointer to void (unused at
present) for later use.  That's all from my side.



It should be noted that some of the intrinsics, which use switch/case
for the type/kind selection, limit the effective element size that
they handle to the maximum value of size_t, less 7 bits. A bit of
straightforward work there would fix this limitation and would allow
the GFC_DTYPE shifts and masks to be eliminated.


Hmm, is this a hidden ABI break, then?


No.

This concerns code like

  type_size = GFC_DTYPE_TYPE_SIZE(array);

  switch(type_size)
{
case GFC_DTYPE_LOGICAL_1:
case GFC_DTYPE_INTEGER_1:
case GFC_DTYPE_DERIVED_1:
  pack_i1 ((gfc_array_i1 *) ret, (gfc_array_i1 *) array,
   (gfc_array_l1 *) mask, (gfc_array_i1 *) vector);
  return;

for example in patck_generic.c.

I think that, if we commit Paul's patch now, we can then fix these cases
before gcc 8 is released.  This is rather straigtforward.

Regards

Thomas

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

[Janne Blomqvist]

On Mon, Jan 22, 2018 at 9:12 PM, Paul Richard Thomas
 wrote:
> This patch has been triggered by Thomas's recent message to the list.
> Not only did I start work late relative to stage 3 but debugging took
> somewhat longer than anticipated. Therefore, to get this committed
> asap, we will have to beg the indulgence of the release managers and
> prompt review and/or testing by fortran maintainers. (Dominique has
> already undertaken to test -m32.)

I think that if we can "guarantee" that we're happy with the current
ABI for GCC 9 (and hopefully 10, 11, ...?) we have a quite strong case
for committing it now. But if anybody if planning on doing some
ABI-breaking work in the foreseeable future then maybe we should wait
until GCC 9 stage1 opens. Anybody with such plans?

> The patch delivers rank up to 15 for F2008, the descriptor information
> needed to enact the F2018 C descriptor macros and an attribute field
> to store such information as pointer/allocatable, contiguous etc..
> Only the first has been enabled so far but it was necessary to submit
> the array descriptor changes now to avoid any further ABI breakage in
> 9.0.0.
>
> 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;
>
> This choice was intended to reduce the changes to a minimum, since in
> most references to the dtype, one dtype is assigned to another.

The only potential objection I can come up with is that if we at some
point want to make the F2018 C interoperability descriptor the native
descriptor type, then we have to mash those fields into the parent
descriptor anyway.  But I don't really think this is a very strong
objection, as I don't think it's a huge difference in the amount of
work whichever path is taken. If this is the easiest path for now, so
be it.

> The F2018 interop defines the 'type and 'attribute fields to be signed
> char types. I used this intially but found that using int was the best
> way to silence the warnings about padding since it also allows for
> more attribute information to be carried.

To be pedantic, F2018 doesn't require that they be signed char, it's
just what I wrote on https://gcc.gnu.org/wiki/ArrayDescriptorUpdate as
*one* potential implementation of ISO_Fortran_binding.h. What the
(draft) F2018 standard says is:

CFI_attribute_t is a typedef name for a standard integer type capable
of representing the values of the attribute codes.

CFI_type_t is a typedef name for a standard integer type capable of
representing the values for the supported type specifiers.

CFI_rank_t is a typedef name for a standard integer type capable of
representing the largest supported rank.

So using int is standard conforming.

(elem_len and version are explicitly specified to be size_t and int,
respectively)

> It should be noted that some of the intrinsics, which use switch/case
> for the type/kind selection, limit the effective element size that
> they handle to the maximum value of size_t, less 7 bits. A bit of
> straightforward work there would fix this limitation and would allow
> the GFC_DTYPE shifts and masks to be eliminated.

Hmm, is this a hidden ABI break, then? Are you saying that even after
this patch we encode the type/kind into the elem_len field? If at some
point we stop doing that and use the type field, it's an ABI break
even though the descriptor layout doesn't change?

(I haven't had time to look into the patch itself, yet. If we decide
to do this for GCC 8 I'll try to find some time.)


-- 
Janne Blomqvist

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

[Paul Richard Thomas]

This patch has been triggered by Thomas's recent message to the list.
Not only did I start work late relative to stage 3 but debugging took
somewhat longer than anticipated. Therefore, to get this committed
asap, we will have to beg the indulgence of the release managers and
prompt review and/or testing by fortran maintainers. (Dominique has
already undertaken to test -m32.)

The patch delivers rank up to 15 for F2008, the descriptor information
needed to enact the F2018 C descriptor macros and an attribute field
to store such information as pointer/allocatable, contiguous etc..
Only the first has been enabled so far but it was necessary to submit
the array descriptor changes now to avoid any further ABI breakage in
9.0.0.

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;

This choice was intended to reduce the changes to a minimum, since in
most references to the dtype, one dtype is assigned to another.

The F2018 interop defines the 'type and 'attribute fields to be signed
char types. I used this intially but found that using int was the best
way to silence the warnings about padding since it also allows for
more attribute information to be carried.

Some parts of the patch (eg. in get_scalar_to_descriptor_type) look as
if latent bugs were uncovered by the change to the descriptor. If so,
the time spent debugging was well worthwhile.

It should be noted that some of the intrinsics, which use switch/case
for the type/kind selection, limit the effective element size that
they handle to the maximum value of size_t, less 7 bits. A bit of
straightforward work there would fix this limitation and would allow
the GFC_DTYPE shifts and masks to be eliminated.

Bootstraps and regtests on FC23/x86_64 - OK for trunk?

Paul

2018-22-01  Paul Thomas  

PR fortran/37577
* array.c (gfc_match_array_ref): If standard earlier than F2008
it is an error if the reference dimension is greater than 7.
libgfortran.h : Increase GFC_MAX_DIMENSIONS to 15. Change the
dtype masks and shifts accordingly.
* trans-array.c (gfc_conv_descriptor_dtype): Use the dtype
type node to check the field.
(gfc_conv_descriptor_dtype): Access the rank field of dtype.
(duplicate_allocatable_coarray): Access the rank field of the
dtype descriptor rather than the dtype itself.
* trans-expr.c (get_scalar_to_descriptor_type): Store the type
of 'scalar' on entry and use its TREE_TYPE if it is ARRAY_TYPE
(ie. a character).
(gfc_conv_procedure_call): Pass TREE_OPERAND (tmp,0) to
get_scalar_to_descriptor_type if the actual expression is a
constant.
(gfc_trans_structure_assign): Assign the rank directly to the
dtype rank field.
(gfc_conv_intrinsic_sizeof): Obtain the element size from the
'elem_len' field of the dtype.
* trans-io.c (gfc_build_io_library_fndecls): Replace
gfc_int4_type_node with dtype_type_node where necessary.
(transfer_namelist_element): Use gfc_get_dtype_rank_type for
scalars.
* trans-types.c : Provide 'get_dtype_type_node' to acces the
dtype_type_node and, if necessary, build it.
The maximum size of an array element is now determined by the
maximum value of size_t.
Update the description of the array descriptor, including the
type def for the dtype_type.
(gfc_get_dtype_rank_type): Build a constructor for the dtype.
Distinguish RECORD_TYPEs that are BT_DERIVED or BT_CLASS.
(gfc_get_array_descriptor_base): Change the type of the dtype
field to dtype_type_node.
(gfc_get_array_descr_info): Get the offset to the rank field of
the dtype.
* trans-types.h : Add a prototype for 'get_dtype_type_node ()'.
* trans.h : Define the indices of the dtype fields.

2018-22-01  Paul Thomas  

PR fortran/37577
* gfortran.dg/coarray_18.f90: Allow dimension 15 for F2008.
* gfortran.dg/coarray_lib_this_image_2.f90: Change 'array1' to
'array01' in the tree dump comparison.
* gfortran.dg/coarray_lib_token_4.f90: Likewise.
* gfortran.dg/inline_sum_1.f90: Similar - allow two digits.
* gfortran.dg/rank_1.f90: Allow dimension 15 for F2008.

2018-22-01  Paul Thomas  

PR fortran/37577
* caf/single.c (_gfortran_caf_failed_images): Access the 'type'
and 'elem_len' fields of the dtype instead of the shifts.
(_gfortran_caf_stopped_images): Likewise.
* intrinsics/associated.c (associated): Compare the 'type' and
'elem_len' fields instead of the dtype.
* caf/date_and_time.c : Access the dtype fields rather using
shifts and masks.
* io/transfer.c (transfer_array ): Comment on item count.
(set_nml_var,st_set_nml_var): Change dtype type and use fields.
(st_set_nml_dtio_var): Likewise.
* libgfortran.h : Change definition of GFC_ARRAY_DESCRIPTOR and
add a