[Bug tree-optimization/93231] [10 Regression] ICEs since r280132

[jakub at gcc dot gnu.org]

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.