aboutsummaryrefslogtreecommitdiff
path: root/gcc/tree-ssa-math-opts.c
diff options
context:
space:
mode:
authorRichard Sandiford <richard.sandiford@arm.com>2019-07-29 18:50:25 +0000
committerRichard Sandiford <rsandifo@gcc.gnu.org>2019-07-29 18:50:25 +0000
commit5d5bb9bc26bbd714ef81a7eb91e77e312582ccdc (patch)
tree83bf374fb969d0c189428c6b47e87b52b4cff13f /gcc/tree-ssa-math-opts.c
parent5c6aa9a8919cbf0dcf3c375f51012720bfb5f3a1 (diff)
downloadgcc-5d5bb9bc26bbd714ef81a7eb91e77e312582ccdc.zip
gcc-5d5bb9bc26bbd714ef81a7eb91e77e312582ccdc.tar.gz
gcc-5d5bb9bc26bbd714ef81a7eb91e77e312582ccdc.tar.bz2
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
Diffstat (limited to 'gcc/tree-ssa-math-opts.c')
0 files changed, 0 insertions, 0 deletions