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
