https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101266
--- Comment #11 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Roger Sayle <[email protected]>: https://gcc.gnu.org/g:e46d96d20bbfa786d30c9371631da00939845f05 commit r17-2413-ge46d96d20bbfa786d30c9371631da00939845f05 Author: Roger Sayle <[email protected]> Date: Wed Jul 15 12:26:16 2026 +0100 PR middle-end/123236: Simplify (int)((long long)x >> 4) This patch addresses a code quality regression on x86_64 related to PR 123236. That original PR (and the related PR 101266) concern tree level optimizations, where this problem should also be fixed, but it also reveals a regression in the RTL optimizers. A motivating test case (on x86_64) is: int bar(int a) { long long t = a; return t >> 4; } Currently -O2 generates a 64-bit shift: bar: movslq %edi, %rax sarq $4, %rax ret with this patch we now generate a 32-bit shift: bar: movl %edi, %eax sarl $4, %eax ret The underlying cause of the RTL-level regression is that some RTL expressions that were previously expressed as {ZERO,SIGN}_EXTEND are now sometimes represented as the equivalent {ZERO,SIGN}_EXTRACT, and that not all simplifications of TRUNCATE({ZERO,SIGN}_EXTEND) are implemented for TRUNCATE({ZERO,SIGN}_EXTRACT). Thanks to Segher, simplify_rtx does handle some truncations of extracts, see https://gcc.gnu.org/pipermail/gcc-patches/2016-November/463629.html but unfortunately this code (and subsequent tweaks) doesn't quite match the cases that appear here. 2026-07-15 Roger Sayle <[email protected]> gcc/ChangeLog PR rtl-optimization/123236 * simplify-rtx.cc (simplify_context::simplify_truncation): Handle cases where a ZERO_EXTRACT or SIGN_EXTRACT has a different mode to (but at least as wide as) its first operand. gcc/testsuite/ChangeLog PR rtl-optimization/123236 * gcc.target/i386/pr123236-1.c: New test case.
