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!