ssa_name_has_boolean_range vs signed-boolean:31 types

This turns out to be a latent bug in ssa_name_has_boolean_range
where it would return true for all boolean types but all of the
uses of ssa_name_has_boolean_range was expecting 0/1 as the range
rather than [-1,0].
So when I fixed vector lower to do all comparisons in boolean_type
rather than still in the signed-boolean:31 type (to fix a different issue),
the pattern in match for `-(type)!A -> (type)A - 1.` would assume A (which
was signed-boolean:31) had a range of [0,1] which broke down and sometimes
gave us -1/-2 as values rather than what we were expecting of -1/0.

This was the simpliest patch I found while testing.

We have another way of matching [0,1] range which we could use instead
of ssa_name_has_boolean_range except that uses only the global ranges
rather than the local range (during VRP).
I tried to clean this up slightly by using gimple_match_zero_one_valuedp
inside ssa_name_has_boolean_range but that failed because due to using
only the global ranges. I then tried to change get_nonzero_bits to use
the local ranges at the optimization time but that failed also because
we would remove branches to __builtin_unreachable during evrp and lose
information as we don't set the global ranges during evrp.

OK? Bootstrapped and tested on x86_64-linux-gnu.

	PR tree-optimization/110817

gcc/ChangeLog:

	* tree-ssanames.cc (ssa_name_has_boolean_range): Remove the
	check for boolean type as they don't have "[0,1]" range.

gcc/testsuite/ChangeLog:

	* gcc.c-torture/execute/pr110817-1.c: New test.
	* gcc.c-torture/execute/pr110817-2.c: New test.
	* gcc.c-torture/execute/pr110817-3.c: New test.

0 files changed, 0 insertions, 0 deletions