[Bug tree-optimization/124909] gcc.dg/match-shift-cmp-3 fails with -fshort-enums
dhruvc at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Wed Apr 22 16:37:19 GMT 2026
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124909
--- Comment #11 from Dhruv Chawla <dhruvc at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #10)
> The pattern is e.g.
> /* (y << x) == x -> false and (y << x) != x -> true when y != 0. */
> (for cmp (eq ne)
> (simplify
> (cmp:c (nop_convert1? (lshift @0 @1)) (convert2? @1))
> (if (INTEGRAL_TYPE_P (TREE_TYPE (@0))
> && tree_expr_nonzero_p (@0))
> { constant_boolean_node (cmp != EQ_EXPR, type); })))
> so obviously it matches fine for
> _1 = 4294967295 << x;
> x.0_2 = (unsigned int) x;
> D.3011 = _1 == x.0_2;
> where x is 32-bit test_enum, but doesn't match for
> _1 = (int) x;
> _2 = 4294967295 << _1;
> _3 = (unsigned int) x;
> D.3011 = _2 == _3;
> when x is 16-bit or 8-bit test_enum because the lshift doesn't use x but
> (int) x.
Ah, thanks for the explanation - that helps a lot!
> So, you'd need to use (convert3? @1) instead of @1 in the second argument of
> lshift,
> but then (but maybe even when not doing that) one needs to be careful about
> which conversions to allow and which to disallow. I'd be worried about
> narrowing conversions, or when @1 isn't integral at all (say floating point).
Could a (nop_convert3? @1) work?
More information about the Gcc-bugs
mailing list