ranger: Fix up REALPART_EXPR/IMAGPART_EXPR handling [PR104604]

The following testcase is miscompiled since r12-3328.
That change assumed that if rhs1 of a GIMPLE_ASSIGN is COMPLEX_CST, then
that is the value of the lhs of the stmt, but that is not the case always,
only if it is a GIMPLE_SINGLE_RHS stmt.  If it is e.g.
GIMPLE_UNARY_RHS or GIMPLE_BINARY_RHS (the latter happens in the testcase),
then it can be e.g.
__complex__ (3, 0) / var
and the REALPART_EXPR of that isn't 3, but the realpart of the division.
I assume once the ranger can do complex numbers adjust_*part_expr will just
fetch one or the other range from a underlying complex range, but until
then, we should limit this to what r12-3328 meant to do.

2022-02-22  Jakub Jelinek  <jakub@redhat.com>

	PR tree-optimization/104604
	* gimple-range-fold.cc (adjust_imagpart_expr, adjust_realpart_expr):
	Only check if gimple_assign_rhs1 is COMPLEX_CST if
	gimple_assign_rhs_code is COMPLEX_CST.

	* gcc.c-torture/execute/pr104604.c: New test.

0 files changed, 0 insertions, 0 deletions