[PATCH] Fix PR24227, fold_binary type-mismatch

[Roger Sayle]

On Fri, 7 Oct 2005, Richard Guenther wrote:
> Fixing would involve four places if two of them were not actually
> redundant.  Also evaluation order of side-effects of X and a in
> X op (a, Y) is undefined, so we don't have to check for that in
> the case of tcc_binary (we never did for tcc_comparison).

:REVIEWMAIL:

Whether the evaluation order of X and a is undefined or not is a
property of the language front-end, and specified to the middle-end
via flag_evaluation_order which is used in the reorder_operands_p
call(s) that you've removed in your patch.  This allows Java, for
example, to specify that in A() + B(), the generated code always
behaves as if A() were evaluated before B().

It's probably a bug that we weren't treating tcc_binary and
tcc_comparison identically, and there may already be JACKS
failures to confirm that.  Likewise, you may see libjava failures
once your testing completes.


It's probably best to fix the type correctness issue for 4.1,
though if you can also fix the tcc_comparison case before we
enter regressions-only state, that would be great.

Many thanks in advance,


Roger
--