[Bug tree-optimization/104604] [12 Regression]wrong code with -O2 VRP Complex integer division issue since r12-3328

["cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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 <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:d44dc131f48254fccc69ec4178fec030e0e2761d

commit r12-7324-gd44dc131f48254fccc69ec4178fec030e0e2761d
Author: Jakub Jelinek <jakub@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  <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.