This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] PR fortran/59910 -- structure constructor in DATA statement
- From: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- To: "Dominique d'Humières" <dominiq at lps dot ens dot fr>
- Cc: fortran at gcc dot gnu dot org, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 18 Nov 2015 11:23:21 -0800
- Subject: Re: [PATCH] PR fortran/59910 -- structure constructor in DATA statement
- Authentication-results: sourceware.org; auth=none
- References: <5F682D1E-46CB-4301-A182-D1F473ECBF46 at lps dot ens dot fr> <20151118003601 dot GA19804 at troutmask dot apl dot washington dot edu> <20151118010142 dot GA43511 at troutmask dot apl dot washington dot edu>
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