ranger: Fix up REALPART_EXPR/IMAGPART_EXPR handling [PR104604]
authorJakub Jelinek <jakub@redhat.com>
Tue, 22 Feb 2022 09:43:13 +0000 (10:43 +0100)
committerJakub Jelinek <jakub@redhat.com>
Tue, 22 Feb 2022 09:43:13 +0000 (10:43 +0100)
commitd44dc131f48254fccc69ec4178fec030e0e2761d
tree741f4f158e9c6e4750a4852eadabbba6ff6b29ae
parent7e691189ca9c04fdba71ceada1faba62afbc1463
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.
gcc/gimple-range-fold.cc
gcc/testsuite/gcc.c-torture/execute/pr104604.c [new file with mode: 0644]