https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104604
--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:d44dc131f48254fccc69ec4178fec030e0e2761d commit r12-7324-gd44dc131f48254fccc69ec4178fec030e0e2761d Author: Jakub Jelinek <ja...@redhat.com> Date: Tue Feb 22 10:43:13 2022 +0100 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 <ja...@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.
