[Bug c++/91987] -fstrict-eval-order issues

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #4)
> Probably, but aggregate copy of TREE_ADDRESSABLE aggregates might be a
> problem.
> For the arguments, I'm not planning to do anything myself, because I don't
> understand it well, just wanted to raise possible issue.

For this I meant something like:
struct S { S (); ~S (); S (const S &); int s; S operator<< (const S &); };

void
foo ()
{
  S a, b, c;
  c = a << (a.s = 5, b);
}
which according to godbolt all of gcc, clang and icpc handle the same in
-std=c++17 mode, the first argument (this) to the method points to a that has
been modified, then
struct S { S (); ~S (); S (const S &); int s; };
S operator<< (const S &, const S &);

void
foo ()
{
  S a, b, c;
  c = a << (a.s = 5, b);
}

(likewise) and finally
struct S { int s; };
S operator<< (S, S);

void
foo ()
{
  S a, b, c;
  a.s = 1;
  b.s = 2;
  c.s = 3;
  c = a << (a.s = 5, b);
}

This one according to godbolt is handled differently, gcc and icpc will call
the operator with S{5}, S{2}, while clang with S{1}, S{2}.