[Bug c++/110850] New: Evaluation order of assignment operands

[Bug c++/110850] New: Evaluation order of assignment operands

[bugreport0 at proton dot me]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110850

            Bug ID: 110850
           Summary: Evaluation order of assignment operands
           Product: gcc
           Version: 13.2.0
               URL: https://godbolt.org/z/89TPG4eaK
            Status: UNCONFIRMED
          Keywords: diagnostic, wrong-code
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bugreport0 at proton dot me
  Target Milestone: ---

In C++17 in assignment expressions the right-hand side evaluation and its side
effects are sequenced before the left-hand side evaluation and its side
effects, so this snippet

struct Trivial {
  int x;
};

int postincrement(int& i) {
  std::cout << "postincrement\n";
  return i++;
}

int load(int& i) {
  std::cout << "load\n";
  return i;
}

int main() {
  Trivial a[1]{};
  int i = 0;
  (std::cout << "LHS\n", a[postincrement(i)])
      = (std::cout << "RHS\n", Trivial{load(i)});
  std::cout << a->x << '\n';
}

should output "RHS load LHS postincrement 0". Instead, it outputs "RHS LHS
postincrement load 1". Around gcc 7.1 evaluation order seems to have been fixed
in many cases, but not for "aggregate assignment" such as with this Trivial
type.

The URL associated with this report demonstrates several variations of this
example, showing in addition discrepancy between compile- and run-time
behaviour and between optimization levels, and inconsistency in warning
messages in cases other than "aggregate assignment".

Bug report #97288 is related, but it assumes implicit lvalue-to-rvalue
conversion to be part of the right operand evaluation, and in later versions
described behaviour disappears, reappears and finally disappears.