would apply to += and
such?
We shouldn't see += etc of class type here since we already represent
those as CALL_EXPR to the selected operator=, but indeed it could
otherwise apply to +=. Like so?
OK.
-- >8 --
Subject: [PATCH] c++: lvalueness of non-dependent assignment expr [PR114994]
As in the COND_EXPR case, but for non-dependent assignment
> > + expressions created by build_x_modify_expr. */
> > + goto default_;
>
> This seems overly specific, I'd think the same thing would apply to += and
> such?
We shouldn't see += etc of class type here since we alre
On 5/9/24 16:29, Patrick Palka wrote:
On Thu, 9 May 2024, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/14? For trunk as a follow-up I can implement the
mentionted representation change to use CALL_EXPR instead of
MODOP_EXPR for a
On 5/9/24 16:23, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/14? For trunk as a follow-up I can implement the
mentionted representation change to use CALL_EXPR instead of
MODOP_EXPR for a non-dependent simple assignment expression that
On Thu, 9 May 2024, Patrick Palka wrote:
> On Thu, 9 May 2024, Patrick Palka wrote:
>
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > OK for trunk/14? For trunk as a follow-up I can implement the
> > mentionted representation change to use CALL_EXPR instead of
> >
On Thu, 9 May 2024, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> OK for trunk/14? For trunk as a follow-up I can implement the
> mentionted representation change to use CALL_EXPR instead of
> MODOP_EXPR for a non-dependent simple assignment
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/14? For trunk as a follow-up I can implement the
mentionted representation change to use CALL_EXPR instead of
MODOP_EXPR for a non-dependent simple assignment expression that
resolved to an operator= overload.
-- >8
