[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