https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90806
--- Comment #14 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
The fast path in wi::lshift looks suspicious to me:
/* For fixed-precision integers like offset_int and widest_int,
handle the case where the shift value is constant and the
result is a single nonnegative HWI (meaning that we don't
need to worry about val[1]). This is particularly common
for converting a byte count to a bit count.
For variable-precision integers like wide_int, handle HWI
and sub-HWI integers inline. */
if (STATIC_CONSTANT_P (xi.precision > HOST_BITS_PER_WIDE_INT)
? (STATIC_CONSTANT_P (shift < HOST_BITS_PER_WIDE_INT - 1)
&& xi.len == 1
&& xi.val[0] <= (HOST_WIDE_INT) ((unsigned HOST_WIDE_INT)
HOST_WIDE_INT_MAX >> shift))
: precision <= HOST_BITS_PER_WIDE_INT)
{
val[0] = xi.ulow () << shift;
result.set_len (1);
}
else
result.set_len (lshift_large (val, xi.val, xi.len,
precision, shift));
and indeed this was fixed in GCC 10 by:
2019-07-10 Marc Glisse <marc.gli...@inria.fr>
* wide-int.h (wi::lshift): Reject negative values for the fast path.
