I was looking at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97596
and the ranger is constructing some 128 bit constants and calling
wide_int_to_tree to turn them into trees.
In particular, it starts with the value
p r.lower_bound(0)
{<wide_int_storage> = {val = {-65535, 9223372036854775807,
140737488257608}, len = 2, precision = 128}, static is_sign_extended = true}
p r.lower_bound(0).dump()
[0x7fffffffffffffff,0xffffffffffff0001], precision = 128
and proceeds to call
wide_int new_lb = wi::set_bit (r.lower_bound (0), 127)
and creates the value:
p new_lb
{<wide_int_storage> = {val = {-65535, -1, 0}, len = 2, precision = 128},
static is_sign_extended = true}
p new_lb.dump()
[0xffffffffffffffff,0xffffffffffff0001], precision = 128
but when we try to call wide_int_to_tree() on this value, it dies in the
second assert (this is the trap in the PR) :
/* Verify that everything is canonical. */
int l = pcst.get_len ();
if (l > 1)
{
if (pcst.elt (l - 1) == 0)
gcc_checking_assert (pcst.elt (l - 2) < 0);
if (pcst.elt (l - 1) == HOST_WIDE_INT_M1)
gcc_checking_assert (pcst.elt (l - 2) >= 0);
<<<--- here.
}
If i look at the value, its:
p pcst.elt (l - 2)
$18 = -65535
which is clearly not >= 0... it seems to be treating it as a signed
value? So did the set_bit routine do something wrong when creating the
new value?
I cant really read this, but something seems amok...
any ideas?
Andrew
