This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, fortran] PR66681 - Wrong result in assigning this_image() to a complex coarray
- From: Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>
- To: FX <fxcoudert at gmail dot com>
- Cc: "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 10 Sep 2015 20:36:19 +0200
- Subject: Re: [Patch, fortran] PR66681 - Wrong result in assigning this_image() to a complex coarray
- Authentication-results: sourceware.org; auth=none
- References: <CAGkQGiJuEa-MWsOsYMT_xpteb3k+wgX3MwnnwyFWUdrABNer-g at mail dot gmail dot com> <37777B3C-CD77-4D57-BC69-14F6D0F8D331 at gmail dot com>
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