Potential bug with wide_int_storage::set_len

["Andre Vieira (lists)" <Andre dot SimoesDiasVieira at arm dot com>]

Hello,

During the development of a patch I encountered some strange behavior
and decided to investigate. The result of which is I think I found a bug
with 'wide_int_storage::set_len' in gcc/wide-int.h.

The function reads:
inline void
wide_int_storage::set_len (unsigned int l, bool is_sign_extended)
{
  len = l;
  if (!is_sign_extended && len * HOST_BITS_PER_WIDE_INT > precision)
    val[len - 1] = sext_hwi (val[len - 1],
                             precision % HOST_BITS_PER_WIDE_INT);
}

Now assume you have a wide_int_storage, lets call it 'result' with the
following values:
val = [ 0x00000000FFFFFFFF, ...];
len = 1;
precision = 32;

Say you are running it on a 64-bit host:
#define HOST_BITS_PER_WIDE_INT 64

and you call 'result.set_len (1, false);'

Then this will sign extend the first element of val, to
0xFFFFFFFFFFFFFFFF, and I don't think this is what you want.

Due to this, 'expand_expr' will expand a constant tree with unsigned
integer type and value MAX_UINT to a rtx node (const_int -1).

Am I missing something here?

Cheers,
Andre

PS: I will be running tests with a patch to remove the negation in front
of 'is_sign_extended' and post the patch in gcc-patches. If anyone
thinks this is wrong and wants to spare me the effort please reply!