https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126054
--- Comment #2 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-16 branch has been updated by Stefan Schulze Frielinghaus <[email protected]>: https://gcc.gnu.org/g:e8835fd25288bce6cbb11c36e18486a0f10559ef commit r16-9254-ge8835fd25288bce6cbb11c36e18486a0f10559ef Author: Stefan Schulze Frielinghaus <[email protected]> Date: Wed Jul 1 15:10:28 2026 +0200 s390: Fix *extzv_<mode>_{srl,sll}<clobbercc_or_nocc> [PR126054] Pattern *extzv_<mode>_sll<clobbercc_or_nocc> matches a left shift followed by anding a contiguous bitmask which is supposed to be implemented by instruction RISBG. Vacated bits of a left shift are zeroed whereas RISBG performs a left rotate, i.e., each bit shifted out of the leftmost bit position is placed in the rightmost position of the operand. Thus, those bits are not necessarily zero. However, the insn does not adapt the bitmask in order to compensate for this. For example, the pattern matches r2 = (r3 << 1) & 255 which leads to risbgn %r2,%r3,56,128+63,1 whereas expected is risbgn %r2,%r3,56,128+62,1 Since the bitmask isn't adjusted the end bit includes the supposedly vacated bit which for RISBG means that this equals the highest bit instead of being zero always. So far combine was gentle enough to adjust the bitmask which covered this up. However, late_combine does not which is why this is being exposed since r15-1579-g792f97b44ff. A similar argument holds for *extzv_<mode>_srl<clobbercc_or_nocc>. Fixed by adjusting the bitmasks for the output templates. PR target/126054 gcc/ChangeLog: * config/s390/s390.md: Fix extzv_<mode>_{srl,sll}<clobbercc_or_nocc> by adjusting the bitmasks in the output templates. gcc/testsuite/ChangeLog: * gcc.target/s390/pr126054.c: New test. (cherry picked from commit 5c55e923bcf191dbfdf65467b04e21c27adba1d6)
