https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93231
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Wilco from comment #4)
> I guess TREE_INT_CST_LOW should fix that. The goal is to support signed and
> unsigned types.
Maybe. Though, perhaps you want to zero extend the constant from the type's
precision to HOST_BITS_PER_WIDE_INT too.
> I'm adding an extra tree_fits_uhwi for that.
Ok.
> I'll check but I think this check is no longer required.
I guess it wouldn't work if the constants are 64-bit, because then tree_to_shwi
might not work for them.
> I can add a generic testcase as well.
Great.
> > And I don't see a check that if it is a STRING_CST, the array elements must
> > be
> > bytes and not wider, which the function assumes (e.g. if it is u"..."[(x &
> > -x) > * ...) >> 27]).
>
> Right now "abc"[] can't match - the constructor always returns an error for
> this case. And this doesn't seem a common idiom so adding support isn't
> useful.
But you do have check_ctz_string, so let's talk about const type var[] =
u"abcd"; or const type var[] = "defg";
I was just lazy to construct an u"\x...\x...\x......" string that would trigger
with check_ctz_string reading it as by array, when at runtime it would actually
be treated as short array etc.
For the non-zero stuff, perhaps you could if (tree_expr_nonzero_p (res_ops[0]))
{ zero_ok = true; zeroval = 0; ctzval = 0; } or so, because if x is not zero,
then you don't need to bother with it, don't need to & mask at the end or punt
etc.
