[PATCH] PR fortran/59910 -- structure constructor in DATA statement

[PATCH] PR fortran/59910 -- structure constructor in DATA statement

[Steve Kargl]

[-- Attachment #1: Type: text/plain, Size: 777 bytes --]

Here's what looks like a fairly simple patch, but it leads
to a question.  Why does gfortran not try to reduce the 
components in a structure constructor in general?  I've
hidden the gfc_reduce_init_expr() behind a check for a
DATA statement, but I suspect gfc_reduce_init_expr() 
may be useful for PARAMETER statements as well (need to
check this!).

Anyway, the patch has been built and tested on x86_64-*-freebsd.
A slightly different patch was built and tested on i386-*-freebsd.

OK to commit?

2015-11-17  Steven G. Kargl  <kargl@gcc.gnu.org>

	PR fortran/59910
	* primary.c (gfc_match_structure_constructor): Reduce a structure
	constructor in a DATA statement.

2015-11-17  Steven G. Kargl  <kargl@gcc.gnu.org>

	PR fortran/59910
	* gfortran.dg/pr59910.f90:

-- 
Steve

[-- Attachment #2: pr59910.diff --]
[-- Type: text/x-diff, Size: 1018 bytes --]

Index: gcc/fortran/primary.c
===================================================================
--- gcc/fortran/primary.c	(revision 230497)
+++ gcc/fortran/primary.c	(working copy)
@@ -2722,6 +2722,12 @@ gfc_match_structure_constructor (gfc_sym
       return MATCH_ERROR;
     }
 
+  /* If a structure constructor is in a DATA statement, then each entity
+     in the structure constructor must be a constant.  Try to reduce the
+     expression here.  */
+  if (gfc_in_match_data ())
+    gfc_reduce_init_expr (e);
+
   *result = e;
   return MATCH_YES;
 }
Index: gcc/testsuite/gfortran.dg/pr59910.f90
===================================================================
--- gcc/testsuite/gfortran.dg/pr59910.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr59910.f90	(working copy)
@@ -0,0 +1,11 @@
+! { dg-do compile }
+! PR fortran/59910
+!
+program main
+  implicit none
+  type bar
+      integer :: limit(1)
+  end type
+  type (bar) :: testsuite
+  data testsuite / bar(reshape(source=[10],shape=[1])) /
+end

Re: [PATCH] PR fortran/59910 -- structure constructor in DATA statement

[Jerry DeLisle]

On 11/17/2015 12:34 PM, Steve Kargl wrote:
> Here's what looks like a fairly simple patch, but it leads
> to a question.  Why does gfortran not try to reduce the 
> components in a structure constructor in general?  I've
> hidden the gfc_reduce_init_expr() behind a check for a
> DATA statement, but I suspect gfc_reduce_init_expr() 
> may be useful for PARAMETER statements as well (need to
> check this!).
> 
> Anyway, the patch has been built and tested on x86_64-*-freebsd.
> A slightly different patch was built and tested on i386-*-freebsd.
> 
> OK to commit?
> 
OK, Can't answer your question above at the moment.

Jerry

Re: [PATCH] PR fortran/59910 -- structure constructor in DATA statement

[Dominique d'Humières]

> … but I suspect gfc_reduce_init_expr() 
> may be useful for PARAMETER statements as well (need to
> check this!).

As in the following test

  module m
    implicit none
    type t
      integer :: i
    end type t
    type(t), dimension(2), parameter :: a1  = (/ t(1), t(2) /)
    type(t), dimension(1), parameter :: c = spread ( a1(1), 1, 1 )
  end module m

? Compiling it with the patch gives the ICE

f951: internal compiler error: in gfc_conv_array_initializer, at fortran/trans-array.c:5704

Otherwise the test succeeds with the patch.

Thanks for working on these PRs,

Dominique

Re: [PATCH] PR fortran/59910 -- structure constructor in DATA statement

[Steve Kargl]

On Wed, Nov 18, 2015 at 12:24:29AM +0100, Dominique d'Humières wrote:
> > ??? but I suspect gfc_reduce_init_expr() 
> > may be useful for PARAMETER statements as well (need to
> > check this!).
> 
> As in the following test
> 
>   module m
>     implicit none
>     type t
>       integer :: i
>     end type t
>     type(t), dimension(2), parameter :: a1  = (/ t(1), t(2) /)
>     type(t), dimension(1), parameter :: c = spread ( a1(1), 1, 1 )
>   end module m
> 

Yep.  We again arrive at gfc_conv_array_initializer with
expr->expr_type == EXPR_FUNCTION, which isn't handled correctly.

The issue seems deeply rooted in the handling of derived types,
which is actually worse than this!  But, that is definitely for
another day.  See PR67817. :(

-- 
Steve

Re: [PATCH] PR fortran/59910 -- structure constructor in DATA statement

[Steve Kargl]

On Tue, Nov 17, 2015 at 04:36:01PM -0800, Steve Kargl wrote:
> On Wed, Nov 18, 2015 at 12:24:29AM +0100, Dominique d'Humières wrote:
> > > ??? but I suspect gfc_reduce_init_expr() 
> > > may be useful for PARAMETER statements as well (need to
> > > check this!).
> > 
> > As in the following test
> > 
> >   module m
> >     implicit none
> >     type t
> >       integer :: i
> >     end type t
> >     type(t), dimension(2), parameter :: a1  = (/ t(1), t(2) /)
> >     type(t), dimension(1), parameter :: c = spread ( a1(1), 1, 1 )
> >   end module m
> > 
> 
> Yep.  We again arrive at gfc_conv_array_initializer with
> expr->expr_type == EXPR_FUNCTION, which isn't handled correctly.
> 
> The issue seems deeply rooted in the handling of derived types,
> which is actually worse than this!  But, that is definitely for
> another day.  See PR67817. :(
> 

Ugh. gfc_simplify_spread does not actually the use of SPREAD
here, because source->expr_type == EXPR_STRUCTURE which is not
handled.

-- 
Steve

Re: [PATCH] PR fortran/59910 -- structure constructor in DATA statement

[Steve Kargl]

On Tue, Nov 17, 2015 at 05:01:42PM -0800, Steve Kargl wrote:
> On Tue, Nov 17, 2015 at 04:36:01PM -0800, Steve Kargl wrote:
> > On Wed, Nov 18, 2015 at 12:24:29AM +0100, Dominique d'Humières wrote:
> > > > ??? but I suspect gfc_reduce_init_expr() 
> > > > may be useful for PARAMETER statements as well (need to
> > > > check this!).
> > > 
> > > As in the following test
> > > 
> > >   module m
> > >     implicit none
> > >     type t
> > >       integer :: i
> > >     end type t
> > >     type(t), dimension(2), parameter :: a1  = (/ t(1), t(2) /)
> > >     type(t), dimension(1), parameter :: c = spread ( a1(1), 1, 1 )
> > >   end module m
> > 
> > Yep.  We again arrive at gfc_conv_array_initializer with
> > expr->expr_type == EXPR_FUNCTION, which isn't handled correctly.
> > 
> > The issue seems deeply rooted in the handling of derived types,
> > which is actually worse than this!  But, that is definitely for
> > another day.  See PR67817. :(
> 
> Ugh. gfc_simplify_spread does not actually the use of SPREAD
> here, because source->expr_type == EXPR_STRUCTURE which is not
> handled.

Dominiq,

I plan to commit my patch and close this PR as the patch
fixes the issue raised in the PR.  I think the above
code highlights a specific issue with SPREAD, and a new PR
should be committed.
-- 
Steve

Re: [PATCH] PR fortran/59910 -- structure constructor in DATA statement

[Steve Kargl]

On Wed, Nov 18, 2015 at 11:23:21AM -0800, Steve Kargl wrote:
> On Tue, Nov 17, 2015 at 05:01:42PM -0800, Steve Kargl wrote:
> > On Tue, Nov 17, 2015 at 04:36:01PM -0800, Steve Kargl wrote:
> > > On Wed, Nov 18, 2015 at 12:24:29AM +0100, Dominique d'Humières wrote:
> > > > > ??? but I suspect gfc_reduce_init_expr() 
> > > > > may be useful for PARAMETER statements as well (need to
> > > > > check this!).
> > > > 
> > > > As in the following test
> > > > 
> > > >   module m
> > > >     implicit none
> > > >     type t
> > > >       integer :: i
> > > >     end type t
> > > >     type(t), dimension(2), parameter :: a1  = (/ t(1), t(2) /)
> > > >     type(t), dimension(1), parameter :: c = spread ( a1(1), 1, 1 )
> > > >   end module m
> > > 
> > > Yep.  We again arrive at gfc_conv_array_initializer with
> > > expr->expr_type == EXPR_FUNCTION, which isn't handled correctly.
> > > 
> > > The issue seems deeply rooted in the handling of derived types,
> > > which is actually worse than this!  But, that is definitely for
> > > another day.  See PR67817. :(
> > 
> > Ugh. gfc_simplify_spread does not actually the use of SPREAD
> > here, because source->expr_type == EXPR_STRUCTURE which is not
> > handled.
> 
> Dominiq,
> 
> I plan to commit my patch and close this PR as the patch
> fixes the issue raised in the PR.  I think the above
> code highlights a specific issue with SPREAD, and a new PR
> should be committed.

This is now PR fortran/68426

-- 
Steve