* Re: [PATCH] PR fortran/59910 -- structure constructor in DATA statement
@ 2015-11-17 23:24 Dominique d'Humières
2015-11-18 0:36 ` Steve Kargl
0 siblings, 1 reply; 7+ messages in thread
From: Dominique d'Humières @ 2015-11-17 23:24 UTC (permalink / raw)
To: Steve Kargl; +Cc: fortran, gcc-patches
> … 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] PR fortran/59910 -- structure constructor in DATA statement
2015-11-17 23:24 [PATCH] PR fortran/59910 -- structure constructor in DATA statement Dominique d'Humières
@ 2015-11-18 0:36 ` Steve Kargl
2015-11-18 1:01 ` Steve Kargl
0 siblings, 1 reply; 7+ messages in thread
From: Steve Kargl @ 2015-11-18 0:36 UTC (permalink / raw)
To: Dominique d'Humières; +Cc: fortran, gcc-patches
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] PR fortran/59910 -- structure constructor in DATA statement
2015-11-18 0:36 ` Steve Kargl
@ 2015-11-18 1:01 ` Steve Kargl
2015-11-18 19:23 ` Steve Kargl
0 siblings, 1 reply; 7+ messages in thread
From: Steve Kargl @ 2015-11-18 1:01 UTC (permalink / raw)
To: Dominique d'Humières; +Cc: fortran, gcc-patches
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] PR fortran/59910 -- structure constructor in DATA statement
2015-11-18 1:01 ` Steve Kargl
@ 2015-11-18 19:23 ` Steve Kargl
2015-11-18 23:54 ` Steve Kargl
0 siblings, 1 reply; 7+ messages in thread
From: Steve Kargl @ 2015-11-18 19:23 UTC (permalink / raw)
To: Dominique d'Humières; +Cc: fortran, gcc-patches
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] PR fortran/59910 -- structure constructor in DATA statement
2015-11-18 19:23 ` Steve Kargl
@ 2015-11-18 23:54 ` Steve Kargl
0 siblings, 0 replies; 7+ messages in thread
From: Steve Kargl @ 2015-11-18 23:54 UTC (permalink / raw)
To: Dominique d'Humières; +Cc: fortran, gcc-patches
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] PR fortran/59910 -- structure constructor in DATA statement
2015-11-17 20:34 Steve Kargl
@ 2015-11-18 19:10 ` Jerry DeLisle
0 siblings, 0 replies; 7+ messages in thread
From: Jerry DeLisle @ 2015-11-18 19:10 UTC (permalink / raw)
To: Steve Kargl, fortran, gcc-patches
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH] PR fortran/59910 -- structure constructor in DATA statement
@ 2015-11-17 20:34 Steve Kargl
2015-11-18 19:10 ` Jerry DeLisle
0 siblings, 1 reply; 7+ messages in thread
From: Steve Kargl @ 2015-11-17 20:34 UTC (permalink / raw)
To: fortran, gcc-patches
[-- 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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-11-18 23:54 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-17 23:24 [PATCH] PR fortran/59910 -- structure constructor in DATA statement Dominique d'Humières
2015-11-18 0:36 ` Steve Kargl
2015-11-18 1:01 ` Steve Kargl
2015-11-18 19:23 ` Steve Kargl
2015-11-18 23:54 ` Steve Kargl
-- strict thread matches above, loose matches on Subject: below --
2015-11-17 20:34 Steve Kargl
2015-11-18 19:10 ` Jerry DeLisle
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).