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

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 4 Oct 2019, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91987
> 
> --- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> (In reply to rguenther@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.

Well, AFAICS this "optimization" is purely for frontend folding
since in the middle-end we have expressions not "obfuscated" with
COMPOUND_EXPRs.  So I wouldn't mind dropping it completely either...

> 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.

Likewise.  I don't even _want_ to understand :P