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
