https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126504
--- Comment #3 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <[email protected]>: https://gcc.gnu.org/g:acd94fdfa20bf1195061d57a57e85cdd6beaa571 commit r17-2848-gacd94fdfa20bf1195061d57a57e85cdd6beaa571 Author: Jakub Jelinek <[email protected]> Date: Fri Jul 31 09:11:08 2026 +0200 match.pd: Fix 2 further problems with narrow shift count types [PR126504] This is the same problem as in just fixed PR126476, we have patterns which simplify something involving a shift to comparison of the shift count against a compile time determined value. Like in PR126476, if the shift count has a very narrow type like unsigned _BitInt(4) in the example and we want to compare it against something that doesn't fit into that type (like 20), then we miscompile it as comparison against something else (like 4), even when actually it just means that for no valid value the original will ever be true (resp. false), depending on what comparison it is. Now, why we have 4 very similar simplifiers is weird, sure, the first two changed in the last PR were one left shift and one right shift and in both cases powers of two, but here we have two others which look very similar, especially the last one to the first one. 2026-07-31 Jakub Jelinek <[email protected]> PR tree-optimization/126504 * match.pd ((CST1 << A) == CST2 -> A == ctz (CST2) - ctz (CST1)): If cand isn't representable in TREE_TYPE (@1), simplify to cmp == NE_EXPR. (((1 << n) & M) != 0 -> n == log2 (M)): Don't simplify if log2 doesn't fit into TREE_TYPE (@0). * gcc.dg/torture/bitint-105.c: New test.
