https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122772
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords|needs-bisection |
Summary|[13/14/15/16 Regression] |[13/14/15/16 Regression]
|Bit-field expressions |Bit-field expressions
|resulting from assignment |resulting from assignment
|operators and comma |operators and comma
|operators are incorrectly |operators are incorrectly
|rejected when used as the |rejected when used as the
|first operand of a compound |first operand of a compound
|assignment operator |assignment operator since
| |r7-1689
CC| |jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
int foo () { return 0; }
int bar () { return 1; }
int
main ()
{
struct S { int y : 4; } x;
(x.y = foo ()) += bar ();
}
This is rejected since r7-1689-ga25bd9e6a2e5875b330e3303f392a2a7aa9b5251 aka
P0145R2
implementation, in particular the b @= a; rule where a is evaluated before b.
Now, if y is not a bit-field, that change implements it as
(void) (*(int &) (SAVE_EXPR <x.y = foo (), &x.y>) = TARGET_EXPR <D.3006, bar
()>, *(int &) (SAVE_EXPR <x.y = foo (), &x.y>) + D.3006);
which makes sure that the + operands aren't evaluated in arbitrary order, but
that bar () is evaluated first and only after it foo () and the assignment to
x.y.
With bit-fields it isn't possible to do it that way, but I guess we could do it
with the containing aggregate.
