[Bug rtl-optimization/123114] [16 Regression] ICE on valid code at -O{s, 2, 3} with -fno-tree-vrp on x86_64-linux-gnu: in decompose, at rtl.h:2330 since r16-5356

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123114

--- Comment #4 from GCC 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:8834502ce4d47b7088b48f21360934a589f8fb12

commit r16-6404-g8834502ce4d47b7088b48f21360934a589f8fb12
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sat Dec 27 11:45:18 2025 +0100

    simplify-rtx: Fix up (ne (ior (ne x 0) y) 0) simplification [PR123114]

    The following testcase ICEs on x86_64-linux since the PR52345
    (ne (ior (ne x 0) y) 0) simplification was (slightly) fixed.
    It wants to optimize
        (set (reg/i:DI 10 a0)
            (ne:DI (ior:DI (ne:DI (reg:DI 151 [ a ])
                        (const_int 0 [0]))
                    (reg:DI 152 [ b ]))
                (const_int 0 [0])))
    but doesn't check important property of that, in particular
    that the mode of the inner NE operand is the same as the
    mode of the inner NE.
    The following testcase has
    (set (reg:CCZ 17 flags)
        (compare:CCZ (ior:QI (ne:QI (reg/v:SI 104 [ c ])
                    (const_int 0 [0]))
                (reg:QI 98 [ _5 ]))
            (const_int 0 [0])))
    where cmp_mode is QImode, but the mode of the inner NE operand
    is SImode instead, and it attempts to create
      (ne:CCZ (ior:QI (reg/v:SI 104 [ c ]) (reg:QI 98 [ _5 ])) (const_int 0))
    which obviously crashes later on.

    The following patch fixes it by checking the mode of the inner NE operand
    and also by using CONST0_RTX (cmp_mode) instead of CONST0_RTX (mode)
    because that is the mode of the other operand, not mode which is the
    mode of the outer comparison (though, guess for most modes it will still
    be const0_rtx).

    I guess for mode mismatches we could arbitrarily choose some extension
(zero
    or sign) and extend the narrower mode to the wider mode, but I doubt that
it
    would ever match on any target.  But even then we'd need to limit it, we
    wouldn't want to deal with another mode class (say floating point
    comparisons), and dunno about vector modes etc.

    2025-12-27  Jakub Jelinek  <jakub@redhat.com>

            PR rtl-optimization/123114
            * simplify-rtx.cc
(simplify_context::simplify_relational_operation):
            Verify XEXP (XEXP (op0, 0), 0) mode and use CONST0_RTX (cmp_mode)
            instead of CONST0_RTX (mode).

            * gcc.dg/pr123114.c: New test.