This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 02/14] Add D frontend (GDC) implementation.
- From: Iain Buclaw <ibuclaw at gdcproject dot org>
- To: richard dot sandiford at arm dot com
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, Jeff Law <law at redhat dot com>
- Date: Sat, 20 Oct 2018 21:06:20 +0200
- Subject: Re: [PATCH 02/14] Add D frontend (GDC) implementation.
- References: <CABOHX+c1-je7h4sABuyfYzEvnKj=Ev0ExEWYYm9WbbpjjoZY7Q@mail.gmail.com> <CABOHX+cdSFeojsYtTxLt2xa0RE3wT2NN9yrzFQCC6qqvGfQMjw@mail.gmail.com> <87sh18lr30.fsf@arm.com>
On Tue, 16 Oct 2018 at 11:48, Richard Sandiford
<richard.sandiford@arm.com> wrote:
>
> Iain Buclaw <ibuclaw@gdcproject.org> writes:
> > + /* The LHS expression could be an assignment, to which it's operation gets
> > + lost during gimplification. */
> > + if (TREE_CODE (lhs) == MODIFY_EXPR)
> > + {
> > + lexpr = compound_expr (lexpr, lhs);
> > + lhs = TREE_OPERAND (lhs, 0);
> > + }
>
> s/it's/its/. But the code looks a bit odd -- won't you end up with
> double evaluation of the lhs of the MODIFY_EXPR? Or is the creator of
> the MODIFY_EXPR already guaranteed to have wrapped the lhs in a SAVE_EXPR
> where necessary? Probably worth a comment if so.
>
So, this particular block, the sort of code that we're handling looks like this:
(a = 42) += 64;
(foo() = 42) += 64; // foo() returns a reference
Where the LHS of the left assignment is stripped out and re-written as:
a = 42, a = a + 64;
*SAVE_EXPR <foo ()> = 42, *SAVE_EXPR <foo ()> = *SAVE_EXPR <foo ()> + 64;
LHS is guaranteed to be side-effect free here, else it's a bug. I'll
add a comment about this however.
Regards
--
Iain