This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Potential bug with wide_int_storage::set_len


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:

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!

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]