This is the mail archive of the
mailing list for the GCC project.
Potential bug with wide_int_storage::set_len
- From: "Andre Vieira (lists)" <Andre dot SimoesDiasVieira at arm dot com>
- To: gcc at gcc dot gnu dot org
- Date: Wed, 12 Oct 2016 17:02:46 +0100
- Subject: Potential bug with wide_int_storage::set_len
- Authentication-results: sourceware.org; auth=none
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:
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
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?
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!