https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91987
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to rguent...@suse.de from comment #3) > Ick. I'd say we should unconditionally guard the transform > with the appropriate TREE_SIDE_EFFECTS check? See above, wouldn't that mean throwing the optimization away completely, because COMPOUND_EXPRs with no side-effects in the rhs1 should be just optimized into rhs2? Do you mean unconditionally for all binary/comparison ops, or just the shifts/rotates? For languages where it is UB if the side-effects modify the other operands, I don't see anything wrong with continuing with the optimization. The other C++17 rules are summarized in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91415#c5 (though that PR is also unfinished). > > One thing I'm worried about are the special cases where we enforce some > > argument order, evaluate one argument before the other or vice versa. > > For is_gimple_reg_type args it can be just a matter of forcing it into an > > SSA_NAME or a new VAR_DECL, but if a function argument is a structure, > > struct S { int a, b; } c = { 1, 2 }; > > fun (c, (c.b = 3, 5); > > and fun is one of the magic one that enforce operand ordering and the first > > argument needs to be sequenced before the second, what can we do? > > You need to emit an aggregate copy, don't you? Consider 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.
