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

[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

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

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

[Steve Kargl]

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  

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

2015-11-17  Steven G. Kargl  

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

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

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