* [Patch, fortran] PR66681 - Wrong result in assigning this_image() to a complex coarray
@ 2015-09-08 5:44 Paul Richard Thomas
2015-09-08 21:02 ` FX
0 siblings, 1 reply; 3+ messages in thread
From: Paul Richard Thomas @ 2015-09-08 5:44 UTC (permalink / raw)
To: fortran, gcc-patches
[-- Attachment #1: Type: text/plain, Size: 797 bytes --]
Dear All,
This is something of a corner case, where gfc_conv_expr comes back
with a SAVE_EXPR, in the case of complex, scalar, coarray lvalues. The
first field of the SAVE_EXPR is a perfectly viable expression to
assign to, so I have taken that. If anybody out there has a better
solution, please speak up! The testcase is good, anyway....
Discussed on https://groups.google.com/forum/#!topic/opencoarrays/Cl2iK3OfUTs
Bootstrapped and regtested on FC21/x86_64 - OK for trunk?
Paul
2015-09-08 Paul Thomas <pault@gcc.gnu.org>
PR fortran/66681
* trans-expr.c (gfc_trans_assignment_1): If the lvalue is a
complex type and a save_expr, take the field to be assigned to.
2015-09-08 Paul Thomas <pault@gcc.gnu.org>
PR fortran/66681
* gfortran.dg/coarray_40.f90: New test.
[-- Attachment #2: submit.diff --]
[-- Type: text/plain, Size: 1426 bytes --]
Index: gcc/fortran/trans-expr.c
===================================================================
*** gcc/fortran/trans-expr.c (revision 227511)
--- gcc/fortran/trans-expr.c (working copy)
*************** gfc_trans_assignment_1 (gfc_expr * expr1
*** 9269,9274 ****
--- 9269,9281 ----
gfc_add_block_to_block (&loop.post, &rse.post);
}
+ /* Complex scalar coarrays sometimes produce a SAVE_EXPR on type conversion.
+ Take the expression to assign to. */
+ if (TREE_CODE (lse.expr) == SAVE_EXPR
+ && TREE_CODE (TREE_TYPE (lse.expr)) == COMPLEX_TYPE
+ && expr1->symtree->n.sym->attr.codimension)
+ lse.expr = TREE_OPERAND (lse.expr, 0);
+
tmp = gfc_trans_scalar_assign (&lse, &rse, expr1->ts,
expr_is_variable (expr2) || scalar_to_array
|| expr2->expr_type == EXPR_ARRAY,
Index: gcc/testsuite/gfortran.dg/coarray_40.f90
===================================================================
*** gcc/testsuite/gfortran.dg/coarray_40.f90 (revision 0)
--- gcc/testsuite/gfortran.dg/coarray_40.f90 (working copy)
***************
*** 0 ****
--- 1,11 ----
+ ! { dg-do compile }
+ ! { dg-options "-fcoarray=single -fdump-tree-original" }
+ ! Test the fix for PR66681.
+ !
+ ! Contributed by Damian Rouson <damian@sourceryinstitute.org>
+ !
+ complex a[*]
+ a = this_image ()
+ print *,this_image (),a
+ end
+ ! { dg-final { scan-tree-dump-times "SAVE_EXPR" 0 "original" } }
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Patch, fortran] PR66681 - Wrong result in assigning this_image() to a complex coarray
2015-09-08 5:44 [Patch, fortran] PR66681 - Wrong result in assigning this_image() to a complex coarray Paul Richard Thomas
@ 2015-09-08 21:02 ` FX
2015-09-10 18:36 ` Paul Richard Thomas
0 siblings, 1 reply; 3+ messages in thread
From: FX @ 2015-09-08 21:02 UTC (permalink / raw)
To: Paul Richard Thomas; +Cc: fortran, gcc-patches
> This is something of a corner case, where gfc_conv_expr comes back
> with a SAVE_EXPR, in the case of complex, scalar, coarray lvalues. The
> first field of the SAVE_EXPR is a perfectly viable expression to
> assign to, so I have taken that. If anybody out there has a better
> solution, please speak up!
If the SAVE_EXPR is a useless one, it should have SAVE_EXPR_RESOLVED_P(…) be true. Then you can simply discard it as you’re doing.
If not, we need to created a temp variable, as simply removing the SAVE_EXPR will lead to multiple side-effects evalution in some cases otherwise.
But I’m curious as to where the SAVE_EXPR is created. As far as I can tell, all SAVE_EXPR in our front-end are created by explicit calls to save_expr(), of which there are very few. I don’t see which one is the culprit here :( But creating a SAVE_EXPR for a LHS is definitely not a good idea in the first place.
FX
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Patch, fortran] PR66681 - Wrong result in assigning this_image() to a complex coarray
2015-09-08 21:02 ` FX
@ 2015-09-10 18:36 ` Paul Richard Thomas
0 siblings, 0 replies; 3+ messages in thread
From: Paul Richard Thomas @ 2015-09-10 18:36 UTC (permalink / raw)
To: FX; +Cc: fortran, gcc-patches
Dear FX,
I am puzzled by this business of the SAVE_EXPR:
First, I agree entirely that it is a mystery as to why the SAVE_EXPR
appears. It does not do so for array elements nor for arrays.
Secondly, as far as I can tell, SAVE_EXPR_RESOLVED_P(…) merely implies
that a pointer to a tree is returned. In fact, it does not seem to
signify a usless expression since, in one case in trans-decl.c, it is
actually used.
Third, I do not see where the side effects will appear. Although this
is a co-array element, assignment to it is a purely local affair. It
has to be explicitly referenced from another process before
communication occurs, does it not? This is where my ignorance surfaces
in full force, however :-(
I don't know what to do with this, other than to dereference a tree
pointer if that appears. Ideally, the SAVE_EXPR should be suppressed
at source, although I do not know how to accomplish that.
I would bemore than happy to act on advice from other maintainers....
Cheers
Paul
On 8 September 2015 at 23:02, FX <fxcoudert@gmail.com> wrote:
>> This is something of a corner case, where gfc_conv_expr comes back
>> with a SAVE_EXPR, in the case of complex, scalar, coarray lvalues. The
>> first field of the SAVE_EXPR is a perfectly viable expression to
>> assign to, so I have taken that. If anybody out there has a better
>> solution, please speak up!
>
> If the SAVE_EXPR is a useless one, it should have SAVE_EXPR_RESOLVED_P(…) be true. Then you can simply discard it as you’re doing.
> If not, we need to created a temp variable, as simply removing the SAVE_EXPR will lead to multiple side-effects evalution in some cases otherwise.
>
> But I’m curious as to where the SAVE_EXPR is created. As far as I can tell, all SAVE_EXPR in our front-end are created by explicit calls to save_expr(), of which there are very few. I don’t see which one is the culprit here :( But creating a SAVE_EXPR for a LHS is definitely not a good idea in the first place.
>
> FX
>
>
--
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.
Groucho Marx
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-09-10 18:36 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-09-08 5:44 [Patch, fortran] PR66681 - Wrong result in assigning this_image() to a complex coarray Paul Richard Thomas
2015-09-08 21:02 ` FX
2015-09-10 18:36 ` Paul Richard Thomas
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).