https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119002
--- Comment #5 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The trunk branch has been updated by Richard Sandiford <rsand...@gcc.gnu.org>: https://gcc.gnu.org/g:1ff01a88c484775fe8b5f1ca46fa24dfe0b14f3d commit r15-7806-g1ff01a88c484775fe8b5f1ca46fa24dfe0b14f3d Author: Richard Sandiford <richard.sandif...@arm.com> Date: Tue Mar 4 10:44:34 2025 +0000 simplify-rtx: Fix up simplify_logical_relational_operation [PR119002] The following testcase is miscompiled on powerpc64le-linux starting with r15-6777. During combine we see: (set (reg:SI 134) (ior:SI (ge:SI (reg:CCFP 128) (const_int 0 [0])) (lt:SI (reg:CCFP 128) (const_int 0 [0])))) The simplify_logical_relational_operation code (in its current form) was written with arithmetic rather than CC modes in mind. Since CCFP is a CC mode, it fails the HONOR_NANS check, and so the function assumes that ge | lt => true. If one comparison is unsigned then it should be safe to assume that the other comparison is also unsigned, even for CC modes, since the optimisation checks that the comparisons are between the same operands. For the other cases, we can only safely fold comparisons of CC mode values if the result is always-true (15) or always-false (0). It turns out that the original testcase for PR117186, which ran at -O, was relying on the old behaviour for some of the functions. It needs 4-instruction combinations, and so -fexpensive-optimizations, to pass in its intended form. gcc/ PR rtl-optimization/119002 * simplify-rtx.cc (simplify_context::simplify_logical_relational_operation): Handle comparisons between CC values. If there is no evidence that the CC values are unsigned, restrict the fold to always-true or always-false results. gcc/testsuite/ * gcc.c-torture/execute/ieee/pr119002.c: New test. * gcc.target/aarch64/pr117186.c: Run at -O2 rather than -O. Co-authored-by: Jakub Jelinek <ja...@redhat.com>
