As the following testcases show (the first one reported, last two
found by code inspection), we need to disallow side-effects
in simplifications that turn some unconditional expression into conditional
one.  From my little understanding of genmatch.c, it is able to
automatically disallow side effects if the same operand is used multiple
times in the match pattern, maybe if it is used multiple times in the
replacement pattern, and if it is used in conditional contexts in the match
pattern, could it be taught to handle this case too?  If yes, perhaps
just the first hunk could be usable for 8/9 backports (+ the testcases).

2020-02-15  Jakub Jelinek  <jakub@redhat.com>

	PR tree-optimization/93744
	* match.pd (((m1 >/</>=/<= m2) * d -> (m1 >/</>=/<= m2) ? d : 0,
	A - ((A - B) & -(C cmp D)) -> (C cmp D) ? B : A,
	A + ((B - A) & -(C cmp D)) -> (C cmp D) ? B : A): For GENERIC, make
	sure @2 in the first and @1 in the other patterns has no side-effects.

	* gcc.c-torture/execute/pr93744-1.c: New test.
	* gcc.c-torture/execute/pr93744-2.c: New test.
	* gcc.c-torture/execute/pr93744-3.c: New test.