Fix inchash handling of wide_ints (PR91242)
authorRichard Sandiford <richard.sandiford@arm.com>
Mon, 29 Jul 2019 18:50:25 +0000 (18:50 +0000)
committerRichard Sandiford <rsandifo@gcc.gnu.org>
Mon, 29 Jul 2019 18:50:25 +0000 (18:50 +0000)
commit5d5bb9bc26bbd714ef81a7eb91e77e312582ccdc
tree83bf374fb969d0c189428c6b47e87b52b4cff13f
parent5c6aa9a8919cbf0dcf3c375f51012720bfb5f3a1
Fix inchash handling of wide_ints (PR91242)

inchash::hash::add_wide_int operated directly on the raw encoding
of the wide_int, including any redundant upper bits.  The problem
with that is that the upper bits are only defined for some wide-int
storage types (including wide_int itself).  wi::to_wide(tree) instead
returns a value that is extended according to the signedness of the
type (so that wi::to_widest can use the same encoding) while rtxes
have the awkward special case of BI, which can be zero-extended
rather than sign-extended.

In the PR, we computed a hash for a "normal" sign-extended wide_int
while the existing entries hashed wi::to_wide(tree).  This gives
different results for unsigned types that have the top bit set.

The patch fixes that by hashing the canonical sign-extended form even
if the raw encoding happens to be different.

2019-07-29  Richard Sandiford  <richard.sandiford@arm.com>

gcc/
* wide-int.h (generic_wide_int::sext_elt): New function.
* inchash.h (hash::add_wide_int): Use it instead of elt.

From-SVN: r273881
gcc/ChangeLog
gcc/inchash.h
gcc/wide-int.h