Hi!
My last change to CONST_WIDE_INT handling in add_const_value_attribute broke
handling of CONST_WIDE_INT constants like ((__uint128_t) 1 << 120).
wi::min_precision (w1, UNSIGNED) in that case 121, but wide_int::from
creates a wide_int that has 0 and 0xff00000000000000ULL in its elts and
precision 121. When we output that, we output both elements and thus emit
0, 0xff00000000000000 instead of the desired 0, 0x0100000000000000.
The following patch fixes that by ensuring the precision is equal to what
we'll actually use, whole multiples of 64 bits.
Bootstrapped/regtested on x86_64-linux and i686-linux.
Though, thinking more about it, maybe better would be to actually pass
machine_mode to add_const_value_attribute from callers, so that we know
exactly what precision we want. Because hypothetically, if say mode is
OImode and the CONST_WIDE_INT value fits into 128 bits or 192 bits,
we'd emit just those 128 or 192 bits but debug info users would expect
256 bits.
2021-11-03 Jakub Jelinek <ja...@redhat.com>
PR debug/103046
* dwarf2out.c (add_const_value_attribute) <case CONST_WIDE_INT>: Round
prec up to next HOST_BITS_PER_WIDE_INT multiple.
--- gcc/dwarf2out.c.jj 2021-10-08 10:52:47.086531820 +0200
+++ gcc/dwarf2out.c 2021-11-02 16:25:24.505504356 +0100
@@ -20102,6 +20102,7 @@ add_const_value_attribute (dw_die_ref di
unsigned int prec = MIN (wi::min_precision (w1, UNSIGNED),
(unsigned int) CONST_WIDE_INT_NUNITS (rtl)
* HOST_BITS_PER_WIDE_INT);
+ prec = ROUND_UP (prec, HOST_BITS_PER_WIDE_INT);
wide_int w = wide_int::from (w1, prec, UNSIGNED);
add_AT_wide (die, DW_AT_const_value, w);
}
Jakub
